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Control  of  the  airspace  over  the  battlefield  is  a 
complex  task.  The  control  and  reporting  center  (CRC),  as 
part  of  the  tactical  air  control  system  (TAGS),  plays  a  vital 
role  in  the  air  defense  mission.  The  purpose  of  this  thesis 
was  to  evaluate  the  utility  of  the  proposed  combat 
identification  system  -  indirect  subsyten  (CIS-ISS),  an 
automated  identification  feature,  within  the  CRC.  This  issue 
was  considered  through  a  comparison  of  the  automated  system 
with  the  current  manual  system  of  identification.  The 
primary  measure  of  comparison  was  the  number  of  hostile 
aircraft  prosecuted  during  the  first  "wave"  of  a  massive 

conventional  attack. 

\ 

Transient  Air  Defense  Zone  (TADZ),  a  large  Fortran  and 
SLA'!  based  simulation  model  of  the  Soviet  air  defense  system 
in  use  at  FT1),  was  modified  to  represent  the  structure  and 
operating  procedure  of  the  TAGS.  Parametric  inputs  were  made 
to  TADZ  based  on  operational  test  and  performance  data  for 
the  CIS-ISS  and  the  CRC.  The  model  was  then  used  to  provide 
data  for  a  statistical  comparison  between  the  automated  and 
manual  identification  systems.  The  results  showed  that  if 
the  CIS-ISS  is  used  in  the  envisioned  centralized  location 
with  u  "man  in  the  loop,"  it  will  back  1 og  under  the  load  of  a 
Central  European  threat.  Distribution  of  the  CIS-ISS  from  a 
centralized  location  and  collection  of  more  reliable  input 
data  are  recommended  areas  for  future  effort. 

vii 


I.  INTRODUCTION 


Background  o f  the  Study 

Two  primary  missions  of  the  United  States  Air  Force  are 
to  "gain  and  maintain  general  air  supremacy"  and  "to 
establish  local  air  superiority"  in  the  support  of  national 
policy  decisions  [DoD  JSOG,  1984:1.14].  Since  the  conclusion 
of  World  War  II,  the  U.S.  has  dedicated  its  political  and 
military  might  to  preserving  the  peace  between  the  Warsaw 
Pact  and  NATO  forces  in  Europe.  In  support  of  this  aim,  the 
U.S.  has  dedicated  a  significant  amount  of  its  military 
forces  to  the  NATO  alliance.  Over  the  past  forty  years, 
advances  in  technology  and  changes  in  the  military  postures 
of  the  opposing  forces  have  significantly  altered  the 
environment  in  Europe  and  thus  have  made  the  air  defense 
mission  of  the  NATO  forces  increasingly  more  complex  in  the 
European  theater.  It  is  estimated  that  in  a  direct 
conventional  conflict  between  NATO  and  the  Warsaw  Pact  more 
than  7,000  aircraft  (2,000  NATO,  5,000  Warsaw  Pact)  could  be 
in  the  air  at  any  one  time;  and  all  this  in  an  airspace 
comparable  to  the  skies  over  the  state  of  Oregon  [Donnelly, 
1985]!  With  the  potential  of  having  so  many  aircraft  in  this 


airspace,  the  task  of  providing  adequate  control  of  NATO's 
air  forces  is  anything  but  a  simple  task.  The  Tactical  Air 
Control  System  (TACS)  was  developed  to  aid  in  this  mission. 

Tactical  Ai r  Control  System  (TACS) 

The  TACS  is  a  network  of  facilities,  equipment,  people 
and  procedures  that  permits  the  Air  Force  Component 
Commander  to  plan,  direct  and  control  tactical  air 
operations.  In  short,  it  is  a  battle  management  system 
[Gardner,  1982:55]. 

This  battle  management  system  consists  of  surveillance 
radars,  missile  batteries,  and  control  centers  all  joined 
together  by  communication  links  for  the  purpose  of 
controlling  the  airspace  over  the  battle  area.  With  the 
great  number  of  aircraft  filling  the  skies  during  a  conflict, 
the  task  of  determining  which  are  hostile  and  which  are 
friendly  is  vital.  With  the  advent  of  the  computer  to  aid  in 
the  TACS  process,  this  particular  problem  has  become  one  of 
information  gathering,  filtering,  and  dissemination  to  the 
appropriate  "decision  nodes"  of  the  air  control  system.  With 
the  aim  of  improving  the  timeliness  and  accuracy  of  aircraft 
identifications  during  wartime,  the  Air  Force  has  contracted 
with  the  General  Dynamics  Corporation  to  develop  the  Combat 
Identification  System  -  Indirect  Subsystem  (CIS-ISS)  [A.F. 
Contract  F19628-83-C-0054,  1983]. 

The  CIS-ISS  is  an  automated  system  made  up  of  hardware 
and  software  designed  to  improve  the  aircraft  identification 
function  during  wartime.  The  CIS-ISS  will  automate  the  data 


normally  used  to  assist  the  operator  in  the  "hostile- 
friendly"  identification  decision.  It  will  also  provide 
specific  aircraft  type  identification  with  an  associated 
probability  of  accuracy.  CIS-ISS  will  be  utilized  in  the 
control  and  reporting  center  (CRC)  node  of  the  TACS.  A  brief 
description  of  the  process  of  the  CRC,  the  senior  radar 
control  unit  in  the  TACS,  is  provided  below. 

CRC  Sys  tem  Process 

The  CRC  is  the  focal  point  for  decentralized  execution 
of  air  defense  and  airspace  control  functions.  The  CRC 
directs  air  defense  operations,  provides  aircraft 
guidance  or  monitoring  for  offensive  and  defensive 
missions,  relays  mission  changes  to  airborne  aircraft 
and  supervises  the  integrated  activities  of  other  radar 
elements  [Gardner,  1982:55]. 

The  CRC  is  the  senior  radar  air  defense  node  of  the  Air 
Force's  tactical  air  control  system.  It  provides  radar 
surveillance  coverage  for  its  assigned  airspace.  It  is  also 
tasked  to  identify  and  assign  air  defense  resources  against 
hostile  and  unknown  aircraft  and  to  ensure  the  safe  passage 
of  friendlies  in  and  out  of  its  area  of  responsibility.  The 
CRC  system  process  involves  three  basic  activities  that  are 
performed  in  a  sequence:  surveillance,  identification  and 
weapons  assignment. 

Surve i 1  lance.  [TACR  55-44,  1985  :3.7-3.13  ]  The  first 

activity  is  the  detection  of  a  radar  return  when  it  appears 
on  the  radar  scope.  The  scope  surveillance  operator  (SSO) 
determines  if  the  return  is  a  valid  one  by  observing  it  for 


one  or  two  sweeps  of  the  radar.  If  the  return  is  valid,  the 
SSO  will  initiate  a  radar  track.  The  operator  must 
continually  update  each  track  entered  into  the  system. 

Tracks  must  be  updated  every  2  minutes  or  every  5  minutes 
depending  on  their  priority.  Priority  1  are  hostile, 
priority  2  are  unknowns,  priority  3  are  emergencies,  priority 
4  are  air  defense  fighters,  priority  5  are  VIP  flights, 
priority  6  are  Special  Missions  and  priority  7  are  others 
[TACR  55-44,  1985:7.1].  As  additional  tracks  enter  the 

system,  they  are  each  initiated  and  updated  in  sequence. 

Movement s  and  Identification  ( M& I ) .  [ TACR  55-44, 

1985:3.13-3.15]  The  second  activity  is  track  identification. 
Regulations  state  "the  maximum  time  allowable  for  initial 
track  identification  is  two  minutes  from  the  time  the  track 
is  established  by  or  received  at  the  TACS  element  responsible 
for  identification"  [TACR  55-44,  1985:3.13].  Mil  may  be 

capable  of  identifying  aircraft  in  less  than  two  minutes  if 
all  available  information  is  provided.  The  track  must  be 
identified  as  one  of  the  following:  assumed  friend,  assumed 
hostile  or  evaluated  as  unknown.  M& I  uses  several  pieces  of 
data  to  correlate  against  the  radar  tracks  for 
identification.  They  use  flight  plan  data  derived  from  the 
air  tasking  order  (ATO)  or  frag  orders,  electronic 
identification  of  IFF/SIF  (identification  friend  or  foe  / 
selective  identification  feature),  airspace  control 
procedures  such  as  corridors  and  LLTR  (low  level  transit 


routes),  and  visual  identification  (e.g.,  pilot  visual 
inspection).  Normally  this  information  is  available  at  the 
work  station  for  the  Mil  operators  to  identify  aircraft.  Some 
data  is  provided  via  the  console  such  as  the  IFF/SIF  and  the 
airspace  control  procedures.  Other  data  must  be  handled 
manually  such  as  the  flight  plan  data.  Here  the  operator 
must  correlate  speed,  altitude  and  heading  of  the  radar  track 
with  facts  about  aircraft  scheduled  to  return  to  a  specific 
recovery  base  at  a  specific  time,  altitude,  heading,  and 
corridor  [TACR  55-44.  1985:3.13-3.14]. 

The  Mil  operator  will  receive  all  of  the  radar  tracks 
pending  identification.  The  operator  will  normally  select 
the  nearest  radar  track  to  identify  first,  the  next  closest, 
etc.  After  two  minutes  the  operator  must  identify  the  radar 
tracks  as  assumed  friend,  assumed  enemy,  or  evaluated 
unknown.  The  declaration  of  assumed  enemy  and  evaluated 
unknown  will  initiate  the  third  activity. 

Weapons  Ass ignment.  [TACR  55-44,  1985:3.5-3.7]  The 

third  activity  is  interception.  In  the  CRC,  the  weapons 
assignment  officer  (WAO)  and  the  weapons  controllers  are  the 
principal  players  in  the  interception  activity.  If  a  radar 
track  is  identified  as  hostile,  the  weapons  assignment 
officer  will  assign  a  weapon  controller  to  that  track  (this 
is  assuming  that  the  WAO  has  decided  to  use  tactical  air 
against  the  target  and  not  air  defense  artillery)  [TACR  55- 


44,  1985:3.5].  The  assigned  weapons  controller  will  then 

take  steps  to  engage  the  target.  For  example,  the  controller 
may  direct  an  interceptor  from  a  combat  air  patrol  to  the 
target  or  an  interceptor  may  be  directed  from  an  air  base. 

The  same  basic  procedure  would  apply  for  an  evaluated 
unknown.  A  weapons  controller  would  have  to  direct  an 
aircraft  from  the  ground  to  obtain  a  positive  identification 
of  the  target.  If  the  target  is  assigned  to  air  defense 
artillery,  a  similar  procedure  would  be  followed.  After  all 
appropriate  steps  are  taken  to  verify  the  hostile 
identification,  the  WAO  will  order  the  target  destroyed  by 
either  an  interceptor  or  a  component  of  the  air  defense 
ar t i 1 lery . 

Problem  Statement 

"The  basic  purpose  of  the  CIS-ISS  Demonstration  Program 
is  to  validate  the  improved  ID  effectiveness  which  is 
predicted  to  result  from  the  fusion  of  multiple  sensors.  ESM 
was  chosen  as  one  of  the  most  potent  sensors  to  be  utilized 
for  the  demonstration  [Schindali,  unda t ed :2 ] ."  The  CIS-ISS 
will  provide  a  more  accurate  identification  (99%  reliable) 
and  allow  the  battle  directors  and  weapon  assignment  officers 
to  initiate  tactical  actions  against  hostile  aircraft  without 
having  to  visually  identify  the  aircraft  prior  to  ordering  an 
engagement  [Perini,  1985:81].  However,  it  is  not  known  what 
the  CIS-ISS  response  rate  should  be  to  ensure  that  aircraft 


identifications  are  being  processed  without  backlog  under 
medium  and  heavy  workload  conditions  (e.g.,  the  potential 
wartime  environment). 

Research  Quest i on 

What  is  the  range  of  the  optimal  response  rate(s)  that 
should  be  incorporated  in  the  proposed  CIS-ISS  to  ensure 
processing  without  backlog  under  combat  conditions?  The 
optimal  response  rate(s)  identified  will  highlight  the 
effects  (trade-offs)  with  other  system  performance  factors 
such  as: 

a.  Track  correlation  accuracy  (radar  system  versus 
CIS-ISS). 

b.  Manual  versus  automated  interfaces. 

c.  Weapon  system  employment  versus  track  identity  (will 
more  accurate  track  identity  affect  levels  of  air 
defense  artillery  or  interceptor  use). 

Subs i d i ary  Quest  ions: 

1.  What  are  the  limiting  factors  of  the  CIS-ISS  to 
provide  automated  radar  track  correlation  with  available 
identification  information  (i.e.  where  is/are  the 

bot t leneck(s) :  the  data  links,  information  processing, 
operator  proficiency,  etc.)? 

2.  What  is  the  arrival  rate  of  aircraft  into  the  TACS 
under  combat  conditions?  This  may  require  research  into 
"exercise"  results  and  possibly  expert  opinion  in  the  case  of 
insufficient  data. 
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3.  How  many  targets  can  the  CRC  operators  ''handle"  in 
the  manual  mode  prior  to  becoming  saturated  or  overloaded? 
Again,  this  may  involve  expert  opinion. 

4.  What  are  the  roles  and  functions  of  each  element  of 
the  TACS?  This  question  will  be  answered  with  emphasis  on 
the  Surveillance  and  the  Movements  and  Identification 
sections  within  the  CRC. 

Assumpt i ons 

Three  major  assumptions  were  made  in  developing  the 
model  for  this  thesis  effort.  First,  it  was  assumed  that  the 
sensors  that  support  and  provide  the  input  to  the  automated 
identification  processor  will  be  colocated  with  each  radar 
site  providing  input  into  the  CRC.  This  assumption  will 
ensure  that  the  identification  sensors  will  match  the 
surveillance  coverage  of  the  radars. 

The  second  assumption  is  about  the  employment  of  the 
automated  identification  processor.  The  users  of  the  CIS-ISS 
have  indicated  that  they  desire  to  retain  a  man  in  the  loop 
and  therefore  the  CRC  will  retain  the  identification  function 
[Jones,  1985].  In  addition,  the  system  as  it  is  now 
envisioned  provides  a  single  console  for  a  CIS-ISS  interface. 
Thus,  a  single  central  identification  processor  was  modeled. 

The  third  assumption  concerned  the  environment  in  which 
the  CIS-ISS  model  would  be  tested.  The  worst  case  scenario 
for  the  TACS  system  is  assumed  to  be  the  NATO  envi  ronment. 
Therefore,  this  initial  research  concentrates  on  a  generic  US 
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TAGS  operation  within  a  central  Europe  type  threat  and  uses 
the  appropriate  threat  intensities,  air  traffic  densities, 


% 

!  I 

i  etc.. 

■ 

Scope  and  Limitations 

1.  Data  Ga t her i ng.  The  scope  of  the  problem  is  limited 
by  the  data  available.  Data  from  the  CIS-ISS  feasibility 
demonstration  at  Eglin  AFB  in  May  1985  is  marginally 
suitable  for  use  in  the  CRC  model  because  of  its  raw  form  and 
the  limited  number  of  data  points  [Preidis,  1985].  When  more 
expanded  data  on  CRC  service  times  becomes  available  from  the 
CIS-ISS  test  conducted  in  Germany  in  the  fall  of  1985,  the 
distributions  will  need  to  be  recalculated.  [Preidis,  1985]. 

In  all  cases,  the  data  used  was  unclassified  because  one  goal 
of  this  thesis  was  to  keep  the  report  unclassified  if  at  all 
poss i ble . 

2.  CIS-ISS  Definition.  The  CIS-ISS/CRC  interface  is 
not  yet  finalized.  Due  to  the  ongoing  research  and 
validation  of  the  CIS-ISS,  the  final  specifications  on  this 
interface  have  not  been  agreed  upon.  The  present  situation 
makes  the  problem  definition  "broader"  because  of  the  lack  of 
preciseness  in  the  definition.  The  level  of  modeling  as  it 
pertains  to  the  CIS-ISS  will  become  more  detailed  as  the 

interface  is  better  defined  by  the  agencies  involved.  The 

i 

|  CIS-ISS  SPO  should  be  able  to  aid  in  defining  the  interface 

i 

j  for  the  purposes  of  this  study  [O'Brien,  1985]. 


Overv i ew  o f  Rema i  n  i  ng  Chapters. 

The  remaining  chapters  parallel  the  research  design 
employed  in  conducting  this  thesis.  Chapter  11  is  the 
literature  review  which  covers  both  the  analysis  and  the 
background  investigation  of  the  problem.  Chapter  III  is  a 
detailed  description  of  the  simulation  methodology  as  applied 
to  this  particular  problem.  Chapter  IV  is  a  description  of 
the  computer  model  itself.  In  Chapter  V,  the  results  and 
statistical  analysis  involved  in  answering  the  research 
question  will  be  discussed.  Finally,  in  Chapter  VI, 
conclusions  are  discussed  based  on  the  experimental  results 
and  recommendations  are  made  regarding  possible  model 
refinements  and  future  research. 


II.  LITERATURE  REVIEW 


Overview 


This  chapter  presents  a  review  of  the  literature  that 
confirms  the  requirement  for  an  automated  aid  for  air  defense 
identification.  The  literature  search  also  establishes  the 
use  of  simulation  as  a  method  of  answering  the  research 
questions  posed  in  Chapter  One.  Specifically  the  literature 
search  was  directed  to  answer  the  following  questions: 

1.  What  are  the  previous  approaches  to  similar 
problems?  A  review  of  study  efforts  on  the  air  defense 
system  is  presented.  The  applicability  of  this  thesis 
effort  is  shown  in  relation  to  the  overall  research 
being  conducted  on  the  Tactical  Air  Control  System. 

2.  Why  is  aircraft  identification  a  problem  in  the 
modern  air  war?  The  military  requirement  for  an 
improved  capability  to  identify  friend  from  foe  is 
established.  In  addition,  the  background  of  the 
specific  automated  identification  capab i 1 i t y /e  1  ec t ron i c 
support  measure  that  was  tested  at  Eglin  Air  Force  Base 
in  Florida  is  presented. 

3.  Why  use  simulation?  A  general  justification  of 
applying  the  use  of  simulation  as  opposed  to  an 
alternative  approach  is  answered.  Included  in  the 
review  is  an  analysis  of  the  types  of  problems  and  the 
requirements  for  the  use  of  simulation.  A  discussion  of 
the  advantages  and  limitations  of  simulation  is  also 
presented . 

4.  What  is  the  appropriate  "design  of  the  experiment?" 

A  literature  search  of  alternative  approaches  to 
designing  an  exper  i  men t /s i mu  la t i on  that  offers  the  best 
design  to  produce  data  that  will  provide  definitive  or 
significant  results.  The  discussion  will  include 
methods  to  reduce  the  number  of  experimental  computer 
simulations  required  to  produce  a  s ta t i s t i ca 1 1 y  valid 
output. 


5.  What  are  the  appropriate  statistical  Pleasures  to  be 
used?  A  review  of  the  standard  accepted  mathematical 
and  statistical  tests  are  outlined  with  a  brief 
description  of  the  procedures  applied. 

Pre v i ous  Research  Efforts 

This  section  will  provide  a  brief  overview  on  other 
research  efforts  involving  similar  topics  for  the  TACS. 

Since  this  thesis  effort  is  unclassified,  the  literature 
search  addresses  the  material  that  is  available  in  the  public 
domain.  The  literature  search  was  directed  to  locate 
available  models  of  an  air  defense  zone.  The  literature 
search  revealed  several  models  that  can  be  classified  into 
the  following  catagories. 

Theater  Mode  Is.  There  are  several  existing  models  that 
simulate  the  theater  level  war.  These  models  simulate  a 
ground  and  air  battle  for  an  entire  geographical  war  zone  and 
are  usually  aggregated  at  a  high  level.  Such  a  high  level 
model  would  include  many  air  defense  zone  sectors.  A  single 
sector  is  the  focus  of  this  thesis  effort.  While  some  of  the 
models  can  simulate  the  individual  sector  area  of  interest 
for  this  thesis,  the  models  do  not  provide  the  means  to 
analyze  the  position  interaction  required  to  answer  the 
effect  of  the  CIS-ISS  on  the  TACS.  The  interaction  between 
the  various  functional  positions  is  not  modeled  to  enough 
level  of  detail  to  be  of  use  in  this  research  effort. 
Interceptor  War  Game,  Keen-Mixed  Air  Battle  Simulator,  and 


ST  RAT  DEFENDER  are  examples  of  the  theater  war  models  that 
model  the  air  defense  system  at  too  high  of  a  level  to  answer 
the  research  question  of  this  thesis.  Several  of  the  current 
theater  level  models  being  used  by  the  Department  of  Defense 
are  listed  in  the  Catalog  o f  War gam i ng  and  Military 
Simulation  Mode  1 s  maintained  by  the  Studies  and  Analysis 
Group  at  the  Pentagon  [Qua t troman i ,  1982]. 

Single  Con  f 1 i c  t  Mode  1 s .  Another  grouping  of  models  that 
simulate  the  combat  results  of  the  individual  battles  between 
single  weapons  systems  are  the  single  conflict  models.  An 
example  would  be  the  air  battle  between  two  aircraft  (1  v  1) 
or  two  flights  of  aircraft  (2  v  2/many).  These  models  are 
usually  used  to  optimize  the  weapons  system  capability  of  the 
individual  weapons  system.  These  models  typically  do  not 
show  the  interaction  of  the  multiple  engagements  or 
successive  engagements  that  are  required  of  the  system  model. 
Because  of  this  limitation  the  models  were  not  investigated 
further.  Several  of  the  specific  system  models  are:  Beyond 
Visual  Range  Air  Combat,  COLLIDE  -  An  Aggregated  Conversion 
Model  for  Air  Combat,  and  Barrier  Air  Defense  Model.  These 
DoD  models  focus  on  system  capabilities  and  do  not  treat  the 
issue  of  varying  the  levels  of  identification  capability 
[Qua t t roman i ,  1982]. 

Sector  and  Reg i ona 1  Ai r  De  fense  Models.  There  are 
several  models  that  simulate  air  defense  systems  of  interest. 
The  first  model  of  interest  is  the  QUEB  model  developed  by 


Alphatech  Inc.  for  the  US  Air  Force  Systems  Command,  Foreign 
Technology  Division  under  contract  for  the  Command  Control 
and  Communications  Systems  Dynamics  (C3SD)  project.  "The 
purpose  of  the  C3SD  project  is  to  develop  tools  and 
techniques  to  assist  scientific  and  technical  (S&T) 
intelligence  analysts  in  addressing  C3  problems  [Merriman, 
1983:i]."  The  other  model  of  interest  is  the  Transient  Air 
Defense  Zone  (TADZ)  model  also  developed  by  Alphatech.  The 
major  difference  between  the  two  models  is  that  the  QUEB 
model  is  an  analytical  model  while  TADZ  is  a  simulation 
model.  "QUEB  is  an  analytical  model  used  to  calculate 
measures  of  effectiveness  and  performance  for  the  C3  system, 
focusing  on  the  time  required  to  perform  missions,  the  amount 
of  penetrator  leakage  from  the  ADZ,  and  the  level  of  resource 
utilization  by  the  system  [Merriman,  1983:10]." 

A  paper  presented  at  the  6th  MIT/ONR  Workshop  on  C3 
Systems  compared  the  two  models  [Merriman,  1983:18-22].  As 
noted  in  the  report  and  in  the  introduction  to  the  Software 
Report  on  TADZ,  the  TADZ  model  was  developed  to  improve  upon 
the  draw  backs  of  the  QUEB  model.  The  TADZ  model  allows  the 
use  of  multiple  types  of  interceptors  and  missiles  to  correct 
the  QUEB  deficiency  which  allowed  only  one  type  of  penetrator 
and  defense  assets.  In  addition,  the  QUEB  model  assumed  a 
steady  state  operational  constraint  when  in  reality  the  air 
defense  cases  needed  to  evaluate  situations  that  did  not  fit 
a  steady  state  model  [Merriman,  1983:9]. 


Background  Informal  ion.  In  addition  to  the  research 
efforts  mentioned  above,  several  other  efforts  provide  an 
excellent  description  of  the  environment  and  function  of  an 
air  defense  system.  Two  magazine  articles  provide  general 
descriptions  of  the  air  defense  system.  The  article 
"Employment  of  Tactical  Air  Control  Radars"  in  the  November 
1982  issue  of  S i gna 1  Magaz i ne  by  Colonel  Robert  E.  Gardner 
provides  an  overview  of  the  TACS.  Colonel  Gardner  was  Chief, 
Weapons  Applications  and  Control  Division,  Directorate  of 
Operations,  Headquarters  USAF  when  he  wrote  the  article.  A 
second  article  entitled  "Tactical  Air  Control  Simulator 
Correlates  to  Real  World"  in  the  April  1985  issue  of  Na  t i ona 1 
Defer.se  also  provides  a  discussion  of  the  functions  and 
interactions  required  to  model  an  air  defense  system. 

For  the  reader  who  is  interested  in  learning  the 
tactical  terminology  for  the  European  theater,  the  paper  "A 
Conceptual  Design  for  Modeling  the  Air  War  in  Central  Europe" 
by  Lt.  Colonel  Dennis  L.  Cole,  provides  a  description  of 
terms  and  a  good  framework  for  understanding  the  interactions 
of  the  army  and  air  forces  required  to  successfully  prosecute 
operations  across  the  war  front  [Cole,  1982]. 

The  Prob 1 em  o  f  Ident i f i cat i on 

While  the  identification  of  specific  deficiencies  or 
requirements  for  an  element  of  the  TACS  is  not  the  intent  of 
this  thesis,  the  need  for  an  improved  capability  to  identify 
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friend  from  foe  is  widely  known.  Headquarters  Tactical  Air 
Command  has  stated  the  requirements  for  an  electronic  support 
measures  (ESM)  sensor: 


the  Tactical  Air  Control  System  (TAGS)  requires  a 
survivable,  passive  sensor  for  the  rapid  identification 
of  hostile  and  non-cooperative  targets  with  a  high 
degree  of  confidence.  The  Statement  of  Operational  Need 
(SON),  305-79,  Sur face-to-Ai r,  Combat  Identification 
Sys tern- Ind i rect  Sub-System  (CIS-ISS)  validates  the  need 
for  this  capability.  The  acquisition  of  an  ESM  sensor 
is  an  initial  step  to  improve  target  identification  of 
both  cooperative  and  non-cooperative  targets  within  the 


tactical  Cl  structure  [HQ  TAC/DRC,  1985:1]. 


Dr.  Joel  Shindall  described  the  need  for  an  improved 
identification  means  in  his  paper  entitled.  "ESM  Sensor  for 
Non-cooperative  Target  Classification."  Dr.  Shindall  first 
describes  the  capabilities  of  the  radar  system  as  follows. 


Modern  radars  excell  in  their  ability  to  detect  and 
track  an  airborne  aluminum  reflector,  i.e.  aircraft, 
however,  since  one  reflection  is  pretty  much  like 
another,  the  radar  by  itself  is  ineffective  at 
distinguishing  the  identity  of  a  target,  as  depicted  in 
Figure  1.  This  shortcoming  is  normally  corrected  by 
using  an  active  IFF  interrogator  mounted  on  the  radar 
to  trigger  coded  responses  from  a  transponder  aboard 
each  aircraft.  The  concern  is  that  existing  IFF 
techniques  may  be  spoofed,  jammed,  or  otherwise  rendered 
ineffective  in  time  of  hostile  engagement.  The  radar 
community  has  developed  additional  techniques  which  will 
undoubtedly  be  of  some  effectiveness,  but  it  appears 
that  conclusive  target  identification  through  radar 
alone  is  a  risky  proposition.  Without  reliable  target 
identification,  the  most  advanced  weapon  systems  are 
rendered  impotent  [Shindall,  undated:2]. 

The  paper  continues  with  a  discussion  of  the  benefits  of  an 

ESM  capability  and  highlights  the  fact  that  the  integration 

of  the  two  systems  would  provide  a  highly  efficient  system. 


GSM  techniques  for  aircraft  identification  utilize  the 
fact  that  an  aircraft,  in  order  to  do  its  job,  is 
literally  "glowing”  in  the  electromagnetic  spectrum. 
Unlike  radar  reflections  which  simply  mirror  the 
characteristics  of  the  radar  transmitter,  the  ESM 
emissions  are  highly  characteristic  of  the  particular 
on-board  emitters  carried  by  the  aircraft.  These 
characteristic  emissions  can  be  detected  and  identified 
by  a  properly  designed  and  integrated  passive  ESM 
system,  as  depicted  in  Figure  2.  The  radar  provides 
azimuth  and  range,  while  the  ESM  provides  azimuth  and 
ID.  The  fusion  of  these  sensors  provides  all  three,  as 
diagrammed  in  Figure  3  [Shindal,  undated:2]. 

Without  the  correct  identification  of  all  possible 

targets  entering  into  the  air  defense  system,  the  possibility 

of  destroying  our  own  forces  is  very  likely.  "Shooting  up  a 

few  tanks  and  planes  at  today's  prices  could  easily  match  the 

billions  needed  for  a  new  IFF  system.  Until  then,  white 

flags  should  be  the  standard  issue  --  at  least  that  standard 

is  universally  accepted  [Defense  Electronics,  1983:36]. 

The  CIS-ISS  was  designed  to  provide  a  solution  to  the 
identification  problem.  Colonel  Ewing,  the  Director  of  the 
Combat  Identification  System  Program  office  at  Wright 
Patterson  Air  Force  Base  Ohio,  described  the  capabilities  as 
follows:  "Ninety-nine  percent  probability  of  correct  ID  is 

possible,  using  a  combination  of  identification  techniques 
[Perini,  1  9  85:81  ]." 

In  an  article  in  the  Air  Force  Magazine  entitled 
"Telling  Ours  from  Theirs"  [Perini,  1985],  the  point  was  made 
that  no  one  system  or  techniques  will  satisfy  all  the 
operational  requirements.  The  article  makes  a  point  of 


showing  that  the  organization  of  the  United  States  Combat 
Identification  System  is  composed  of  many  diverse  elements  as 
the  Taole  I  below  indicates. 


Table  I. 

Organization  of  the  U.S.Combat  Identification  System 


CIS 

Direct  Indirect 

Non 

-cooperat  i  ve 

Subsys  tern 

Subsys  tern 

--Mark  X 

--JTIDS 

--Data  obtained 

--Mode  S 

--E-3A  (AW ACS) 

on  unidentified 

--Mark  XII 

--TPS-43  Radars 

aircraft  using 

--Mark  XV 

--ESM 

special  sensors 

--Other  onboard 

--Other  friendly 

and  processing 

sensors 

sources  of  data 

techn i ques 

Why  Simulation 


Justifying  the  selection  for  the  use  of  simulation  over 

some  of  the  more  classical  methods  of  operations  research  is 

the  purpose  of  this  section.  Before  proceeding  further,  the 

following  definitions  from  the  glossary  of  Venture  Simulat ion 

i  n  War,  Business,  and  Politics  are  presented. 

Simulation  1.  An  operating  representation  of  events 
and  processes. 

2.  A  technique  used  to  study  and  analyze 
the  operation  and  behavior,  by  means  of  models  of 
systems  conditioned  by  human  decision  and/or 
probabilistic  natural  influences  [Hausrath,  1971:318]. 
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Mode  1  1.  A  representation  of  a  real  situation  in 

which  only  those  properties  believed  to  be  relevant  to 
the  problem  being  studied  are  represented. 

2.  A  representation  of  an  object  or 
structure;  and  explanation  or  description  of  a  system,  a 
process,  or  series  of  related  events  [Hausrath, 

1971:315] . 

Only  one  other  term  needs  to  be  clearly  defined  at  the 

outset,  and  that  is  gaming.  The  difference  between  gaming 

and  simulation  is  the  active  participation  of  human  beings 

during  the  exercising  of  the  gaming  model  [Greenberg, 

1981:95].  In  the  recently  published  text  The  Military 

App 1 i ca  t i ons  o  f  Mode  ling,  the  difference  between  wargaming 

and  simulation  is  explained: 

"Wargaming"  precisely  applies  only  to  the  analysis  of 
combat  situations  in  which  human  players  form  a  part  of 
the  decision  process.  Hence,  as  de fined  in  this  text, 
models  are  used  to  support  wargame  analysis,  but  are  not 
wargames  themselves.  "Simulation"  is  a  type  of  model  in 
which  the  objective  is  generally  to  replicate  a 
reasonably  well  understood  process,  and  for  which 
uncertainties  are  treated  by  Monte  Carlo  methods.  It 
hence  assumes  sufficient  knowledge  about  the  process  to 
at  least  specify  its  dynamics  and  the  form  of  its 
probability  distribution  [Battilega  and  Grange, 

1984:  14]  . 


Now  that  the  terms  to  be  used  are  defined,  the  focus 
will  be  on  why  simulation  is  used  as  the  basic  methodology  in 
this  thesis.  First,  the  complexity  and  cost  of  conducting  a 
real  experiment  to  test  the  research  question  is  prohibitive. 
The  second  reason  for  using  simulation  is  the  ability  to 
explore  excursions  or  variations.  The  third  reason  is  that 
the  system  under  study  is  well  defined  and  understood.  The 


remainder  of  this  section  shows  that  these  ideas  are  not  just 
held  by  the  authors  but  are  widely  accepted  and  practiced  in 
the  operations  research  community. 


Complex i ty  Requ ires  Simulation 

Norm an  C.  Dalkey  wrote  as  an  introduction  to  his  chapter 
on  simulation  in  Systems  Ana  lysis  and  Policy  Plann i ng: 

App 1 i cat  ions  i n  De fense 

Simulation  is  a  technique  for  studying  complex  military 
processes.  It  consists  of  an  abstract  representation  of 
the  more  important  features  of  the  situation  to  be 
studied,  designed  to  be  played  through  in  time  either  by 
hand  or  by  computer  [Quade  and  Boucher,  1977:241], 

In  some  cases  it  is  not  so  much  the  complex  nature  of  the 

problem  that  requires  simulation,  rather  social  or  economic 

cost  prohibits  the  testing  or  experimentation  required  to 

produce  a  data  base  upon  which  to  base  a  decision. 

War  is  an  example  of  the  complexity,  the  uncontrolled 
variability,  and  the  impossibility  of  obtaining  and 
recording  desired  data  through  manipulation  and 
observation.  Models  make  it  possible  to  examine, 
manipulate,  and  analyze  certain  aspects  of  performance 
with  greater  precision  and  ease  than  is  permittted  by 
observation  of  the  real-life  process.  A  model,  serving 
as  a  substitute  for  and  a  simplification  of  the  real- 
life  process,  brings  the  task  to  manageable  dimensions 
[Ha us  rath,  1971:98]. 

The  very  process  which  models  sometimes  represent  are 
not  fully  explorable  short  of  war  or  economically 
unacceptable  experiments  [Battilega  and  Grange,  1984:8]. 

Since  the  social  cost  and  complexity  of  designing  a  war  just 
to  evaluate  this  system  is  not  a  feasible  solution,  the 


simulation  alternative  was  selected. 


Si  mu lat i on  as  an  Exper i men  t 


Choosing  simulation  as  a  method  of  studying  a  problem 
can  not  be  based  only  on  the  fact  that  the  complexity  of  a 
live  experiment  is  infeasible.  Even  if  the  right  situation 
could  be  found  to  test  the  system,  a  valid  experimental  test 
requires  the  capability  to  reproduce  the  results  under  the 
same  circumstances  and  the  need  to  test  the  experiment  under 
a  range  of  conditions. 

The  fact  that  the  assumptions  of  the  model  are  explicit 
and  the  results  can  be  duplicated  is  extremely  important 
when  a  sizable  community  with  differing  interests  (for 
example,  the  various  agencies  of  the  Department  of 
Defense)  is  interacting  on  a  problem  [Quade  and  Boucher, 
1977  :  250]  . 

Frequently  the  answer  to  a  problem  may  require  the 
analysts  to  evaluate  the  situation  in  alternative  modes. 

"For  example,  there  may  be  a  need  to  analyze  performance 
under  various  terrain  conditions;  or  alternatively,  a 
senstitivity  [sic]  analysis  involving  many  modifications  of 
equipment  may  be  called  for.  [Shubik,  1975:281]"  In  fact, 
sensitivity  analysis  is  a  primary  reason  for  choosing 
simulation  as  a  methodology.  If  the  model  and  the  simulation 
is  conducted  properly  the  results  can  be  shown  to  be  valid 
over  some  range  of  input  values.  This  analysis  of  the 
sensitivity  of  the  model  is  required  to  show  that  the  results 
obtained  reflect  not  just  one  limited  situation  but  remain 
valid  over  some  known  and  defined  range  of  values  based  on 
the  assumptions  of  the  initial  problem. 


Ordinarily  there  is  no  unique,  "best"  set  of 
assumptions,  but  a  variety  of  possibilities,  each  of 
which  has  some  basis  for  support.  A  good  systems  study 
will  include  sensitivity  test  on  the  assumptions  in 
order  to  find  out  which  ones  really  affect  the  outcome 
and  to  what  extent.  This  enables  the  analyst  to 
determine  where  further  investigation  of  assumptions  is 
needed  and  to  call  the  attention  of  the  decision  maker 
to  possible  dangers  that  might  be  present  [Quade  and 
Boucher,  1977:423]. 


Knowledge  o f  the  System  Required 

Martin  Shubik  describes  the  requirements  to  model  a 
system  in  his  book  Games  for  Soc i e  ty ,  Bus i ness  and  War , 

Toward  a  Theory  o f  Garni ng.  In  talking  about  the  use  of 
operations  research  and  tactical  simulation,  Shubik  states 
"The  requirements  of  a  simulation  of  this  variety  is  that  the 
system  to  be  simulated  is  relatively  well-defined  and  that 
its  components  can  be  accurately  described  and  mathematically 
modeled  [Shubik,  1975:12]." 

The  need  for  the  system  to  be  modeled  to  be  fully 
understood  is  also  reflected  in  the  description  of  the 
anatomy  of  a  model  in  Venture  Simulation  i n  War,  Business  and 
Politics. 

A  model,  serving  as  a  substitute  for  and  a 
simplification  of  the  real-life  process,  brings  the  task 
to  manageable  dimension.  The  model  builder  must, 
however,  understand  the  entire  process  and  the  relation 
of  the  component  systems.  The  model  builder  (one  of  the 
gaming  specialists)  builds  models  piece  by  piece  as 
components  of  a  larger,  complex  system  [Hausrath, 
1971:98]. 


The  same  requirement  is  also  stated  in  1 n  t  roduc  t i on  to 


S i mu  1  a  t ion  and  S  LAM  1  I .  When  describing  the  simulation 
process,  Pritsker  says  that  the  building  of  the  model 
requires  that  the  system  to  be  modeled  be  abstracted  "into 
mathematical-logical  relationships  in  accordance  with  the 
problem  formulation  [Pritsker,  1984:10]."  "The  modeler  must 
understand  the  structure  and  operating  rules  of  the  system 
and  be  able  to  extract  the  essence  of  the  system  without 
including  unnecessary  detail  [Pritsker,  1984:11]."  The 
authors  will  now  show  that  the  air  defense  systems  and 
functions  are  well  understood  and  defined. 

The  successes  in  acquiring  complex  and  expensive  weapons 
systems  for  air  defense  have  been  attributed  to  the  well 
defined  functions  within  the  air  defense  mission  area. 

In  the  article  "C3  I  Evolution  Leaves  a  Lot  to  Chance"  in 
De  fense  Electron i cs ,  air  defense  systems  are  described  as  a 
text  book  example  of  successful  acquisition  because  of  the 
well  defined  functions  and  boundaries  between  the  component 
sy s  terns . 

Operational  missions  are  narrowly  stated  and  well 
understood:  target  detection,  tracking  and 

identification;  threat  evaluation;  weapons  assignment 
and  control;  and  engagement  assessment  [Ablett, 

1984:49]. 


The  article  continues  by  stating  that  just  this  type  of 
explicitly  defined  systems  functions  are  required  to  do 
successful  system  engineering.  Effective  systems  design 
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requires  such  a  well  understood  and  well  documented 
description  in  order  to  decide  which  sensors  will  De  required 
for  spec i f i c  users. 

For  automating  the  air  defense  functions,  the  man- 
machine  interface  was  relatively  easily  achieved. 
Positional  information  could  be  conveniently  and 
naturally  presented  on  a  p lan -pos i t i on- i nd i ca t or  (PPI) 
scope,  which  looks  like  a  map,  an  analog  to  the  "real" 
world.  Symbols  could  be  used  to  represent  the  various 
catagories  of  objects  of  concern.  Amplifying  data  and 
choices  were  also  limited,  and  could  be  identified  in 
advance  [Ablett,  1984:54], 

All  of  these  factors  led  to  the  development  of  efficient  work 
stations  for  the  functional  positions  in  the  air  defense 
mission. 


Exper i mental  Design 

Experiments  are  carried  out  by  investigators  in  all 
fields  of  study  either  to  discover  something  about  a 
particular  process  or  to  compare  the  effect  of  several 
factors  on  some  phenomena.  In  the  engineering  and 
scientific  research  environment,  an  experiment  is 
usually  a  test  (or  trial)  or  series  of  tests.  The 
objective  of  the  experiment  may  either  be  confirmation 
(verify  knowledge  about  the  system)  or  exp  1  ora  t i on 
(study  the  effect  of  new  conditions  on  the  system) 
[Montgomery  1984,  p  1J. 

The  above  quote  is  the  opening  to  the  Montgomery's  book 
Design  and  Ana  lysis  o  f  Exper i men  t  s  and  provides  a  good 
overview  of  what  an  experiment  should  be.  The  purpose  of 
this  thesis  experiment  is  to  explore  the  effect  of  the  new 
condition  (automated  identification)  on  the  system  (the 
existing  TACS).  The  purpose  of  experimental  design,  like  the 
scientific  method,  is  to  provide  a  logical  and  systematic 
approach  to  problem  solving.  Although  the  majority  of  the 


experimental  design  specifics  will  be  discussed  in  Chapter  V, 
this  section  will  briefly  discuss  the  benefits  of 
experimental  design. 

If  an  experiment  is  to  be  performed  most  efficiently, 
then  a  scientific  approach  to  planning  the  experiment 
must  be  employed.  By  the  statistical  design  o f 
exper i ment s ,  we  refer  to  the  process  of  planning  the 
experiment  so  that  appropriate  data  will  be  collected, 
which  may  be  analyzed  by  statistical  methods  resulting 
in  valid  and  objective  conclusions.  The  statistical 
approach  to  experimental  design  is  necessary  if  we  wish 
to  draw  meaningful  conclusions  from  the  data 
[Montgomery,  1984:2]. 

Another  advantage  of  experimental  design  is  the  ability 

to  analyze  multiple  factors  or  influences  on  the  system  with 

a  minimum  number  of  observations. 

We  want  to  return  briefly  to  the  advantages  of  a 
factorial  design  as  compared  with  the  one-factor-at-a- 
time  method.  Suppose  we  take  N  observations.  To 
measure  the  main  effect  of  the  first  factor  we  take  N/2 
observations  at  its  low  level  and  N/2  observations  at 
its  high  level.  In  a  factorial  design  we  distribute  the 
N/2  observations  at  the  low  level  of  factor  1  evenly 
between  the  high  and  low  levels  of  the  remaining  ( k - 1 ) 
factors;  the  same  for  the  N/2  observations  at  the  high 
level  of  factorl.  The  precision  of  our  estimate  of  the 
main  effect  of  the  first  factor  will  not  change,  but  the 
factorial  design  makes  it  possible  to  estimate  the 
effects  of  all  the  other  factors  at  the  same  time. 
[Kleijnen,  1975:319] 


Statistical  Measures 

Compar i ng  A1 t  erna t i ve  Sys  terns.  This  section  will 
outline  the  statistical  methods  that  detect  the  differences 
between  the  two  populations.  The  actual  equations  used  will 
be  explained  in  further  detail  in  Chapter  V.  In  operational 
terms,  a  difference  between  populations  means  that  there  will 


be  some  measurable  difference  between  the  outputs  of  the 
model  with  and  without  the  automated  identification  feature. 
The  difference  will  not  only  be  detected  but  also  ranked  to 
show  one  system's  measure  of  performance  is  higher  or  lower 
than  the  other.  In  statistical  terms  this  is  called  ordering 
popu la  t ions. 

Users  of  statistical  methods  as  well  as  teachers  and 
students  of  statistics  need  to  become  acquainted  with 
ranking  and  selection  procedures,  since  these  techniques 
answer  a  question  that  is  raised  in  many  i  nves t iga t i ons 
but  seldom  answered  by  the  more  traditional  methods  of 
analysis.  In  layman's  terms,  the  question  might  be  one 
of  the  following:  Which  one  (or  ones)  of  several  well- 
defined  groups  is  best  (in  some  well-defined  sense  of 
best)?  Which  of  several  alternative  courses  of  action 
is  best?  [Gibbons  et  al,  1977:vii] 

Law  and  Kelton  in  S i mu  1  a  t i on  Mode  1 i ng  and  Analysis 

recommend  the  use  of  confidence  intervals  between  the  two 

measures  of  merit  produced  by  a  simulation  experiment 

involving  different  systems.  They  recommend  the  use  of  a 

confidence  interval  over  a  difference  of  means  test.  A 

difference  in  means  test 

results  only  in  a  'reject'  or  'fail  to  reject' 
conclusion,  a  confidence  interval  gives  us  this 
information  (according  as  the  confidence  interval  misses 
or  contains  zero,  respectively)  as  well  as  a  measure  of 
the  degree  to  which  the  system  responses  are  likely  to 
d i f  fer ,  FT  at  all.  [Law  and  Kelton,  1982:319  ] 

Law  and  Kelton  also  point  out  that  the  general  procedure 

in  selecting  the  best  of  k  systems  involves  building  a 

confidence  interval  around  the  probability  of  making  the 

'correct  selection'  about  which  system  is  best.  The 

procedure  developed  by  Dudewicz  and  Dalai 


involves  'two  stage'  sampling  from  each  of  the  k 
systems.  In  the  first  stage  we  make  a  fixed  number  of 
replications  of  each  system,  then  we  use  the  resulting 
variance  estimates  to  determine  how  many  additional 
replications  from  each  system  are  necessary  in  a  second 
stage  of  sampling  in  order  to  reach  a  decision.  [Law  and 
Ke 1  ton,  1982  :322  ] 

As  will  be  shown,  the  problem  of  selecting  the  correct 
number  of  runs  or  samples  to  use  is  dependent  on  the 
procedure  to  be  employed  and  the  purpose  of  the  analysis. 

The  reason  the  sample  size  is  not  explicitly  stated  is  the 
value  selected  determines  the  reliability  of  the  experiment 
and  is  a  choice  of  the  person  conducting  the  experiment  and 
the  statistical  procedure  used. 

Kleijnen,  in  Statistical  Techniques  i n  Simulat ion, 
divides  his  survey  of  statistical  procedures  to  be  used  in 
analyzing  simulation  data  into  three  catagories.  The  first 
catagory  is  calculating  the  reliability  of  a  signal 
population  given  a  number  of  samples  (simulation  runs).  The 
second  catagory  is  multiple  compar i sons  procedures  when  the 
sample  sizes  or  the  data  is  given  and  the  analyst  wants  to 
select  or  order  the  'k'  populations.  The  final  catagory  is 
multiple  ranking  procedures  where  the  objective  is  to 
determine  the  number  of  samples  necessary  to  measure  a 
selected  difference  with  a  given  probability  of  being 
correct.  [Kleijnen,  1975:451] 

The  reader  is  cautioned  at  this  point  to  make  the 
distinction  between  the  general  categorization  of  procedures 


described  in  tiie  previous  paragraph.  The  first  category  of 
procedures  is  concerned  with  "problem  of  determining  the 
reliability  of  statements  on  the  mean  of  one  population,  or 
the  difference  between  the  means  of  two  populations,  the 
sample  size  being  fixed  [Kleijnen,  1975:525]."  Note  that 
when  determining  the  difference  between  the  means  we  are  not 
concerned  with  the  actual  value  of  the  individual  means,  onl^ 
that  some  measurable  difference  exists. 

In  the  second  category,  multiple  comparisons,  the 
general  use  of  these  procedures  is  to  compare  multiple 
factors  in  the  initial  screening  of  an  experimental  design. 
The  experimentor  has  an  initial  set  of  data,  ’ k *  populations 
with  nj  (i  =  l,2,...,k)  samples  in  each  population  and  the 
experimentor  wishes  to  determine  which  populations  have 
values  better  than  some  level.  This  type  of  screening  is 
applicable  when  the  experimentor  is  not  yet  looking  for  the 
best  system,  rather  the  goal  is  to  find  which  f ac t ors / 1 e ve 1 s 
influence  the  system  output.  [Kleijnen,  1975:525] 

The  final  category  of  procedures,  multiple  ranking, 
involves  the  selection  of  the  'best  population'.  The 
techniques  determine  the  number  of  observations  necessary  to 
make  the  'best  selection'.  Implicit  in  these  procedures  is 
the  idea  of  an  'indifference  zone',  where  if  the  difference 
is  not  large  enough  to  be  outside  of  this  zone,  the 
experimentor  does  not  want  to  spend  the  effort  to  take 
required  number  of  observations  to  detect  that  small 
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difference,  rather  he  is  willing  to  accept  with  a  high 
probability  that  the  populations  do  not  differ.  In  other 


words,  he  is  indifferent  .  [Kleijnen,  1975:599-601] 

Kleijnen  also  further  divides  the  multiple  ranking 

procedures  based  on  the  types  of  assumptions  made: 

independent  observations,  approximation  of  normal 

distributions,  and  the  type  of  variance  (common,  unequal  or 

unknown)  [Kleijnen,  1975:604-605] 

Gibbons,  Olkin,  and  Sobel  also  describe  many  procedures 

i n  Selecting  and  Order i ng  Popu 1  a  t i ons ,  A  new  Statistical 

Methodology.  Gibbons,  Olkin,  and  Sobel  describe  the 

analytical  aspect  of  the  problem  of  selecting  the  best 
population.  These  problems  are  called  the  determination 
of  sample  size,  the  calculation  of  the  operating 
characteristic  curve,  and  the  estimation  of  the  true 
probability  of  a  correct  selection.  [Gibbons  et  al, 
1977:18] 

In  general,  they  recommend  the  use  of  operating 
characteristic  curves  that  give  a  sample  size  based  on  the 
number  of  systems  compared,  the  delta  (difference  between  the 
means)  to  detect  and  the  probability  of  making  the  correct 
choice  [Gibbon  et  al,  1977:18-19].  It  is  important  to  note 
that  Gibbons,  Olkin  and  Sobel  have  assumed  that  the  first 
stage  of  sampling  has  already  been  accomplished,  i.e.  they 
are  given  the  ' k ’  populations  with  n  j  j  j  samples. 


$ 


Summary 

This  chapter  has  presented  a  review  of  the  appropriate 
literature  to  both  confirm  the  requirement  for  an  automated 
identification  system  and  to  establish  the  use  of  simulation 
as  one  satisfactory  method  of  answering  the  research  question 
posed  in  Chapter  One.  In  addition,  a  review  of  the 
literature  covering  experimental  design  and  statistical 
techniques  was  presented.  Chapter  Three  will  explain  the 
methodology  used  and  expand  on  the  methods  found  in  the 


literature  review. 


III. 


METHODOLOGY 


Overv i ew 

In  this  chapter  the  specific  steps  taken  in  the  research 
will  be  discussed  and  documented.  As  discussed  in  the 
literature  review,  computer  simulation  was  chosen  as  the  main 
technique  to  approach  this  problem.  Of  the  several  reasons 
for  using  simulation  to  solve  this  problem,  perhaps  the  most 
important  one  is  sighted  by  Banks  and  Carson  in  their  text, 

Pi  screte  Event  Sys  tern  Si  mu  1  a  t ion:  "simulation  can  be  used  to 
experiment  with  new  designs  or  policies  prior  to 
implementation,  so  as  to  prepare  for  what  may  happen  [Banks 
and  Carson,  1984:4]." 

Under  the  sponsorship  of  the  Air  Force  Human  Resources 
Laboratory  ( AFHRL)  at  Wright  Patterson  AFB,  OH,  this  research 
effort  was  attempted  to  answer  the  question  of  whether  or  not 
the  proposed  CIS-ISS  will  "improve"  the  identification 
function  in  the  TACS.  The  advantages  of  modeling  the 
interaction  effects  prior  to  purchasing  this  system  should  be 
clear.  For  example,  if  the  new  system  can  be  shown  not  t  o 
improve  the  identification  function,  the  unnecessary  purchase 
of  a  costly  system  could  be  avoided.  The  simulation  model 
developed  in  this  effort  will  also  be  used  by  the  AFHRL  to 
help  answer  human  interaction  questions.  So,  although 


answering  the  research  question  at  hand  is  the  main  purpose 
of  this  thesis,  some  long  term  benefits  should  also  be 
rea 1 i zed  . 

This  chapter  will  cover  the  research  design  of  the  thesis 
effort.  The  background  study  of  the  problem,  the  model 
construction  and  verification,  and  the  experimental  design  will 
all  be  described  as  they  relate  to  this  thesis  effort.  Within  the 
section  on  experimental  design,  the  statistical  techniques  used 
will  be  covered  in  detail.  Finally,  there  will  be  a  short 
discussion  on  some  of  the  techniques  that  helped  keep  the  thesis 
work  "on  track"! 


The  Research  Design 

The  research  plan  or  design  of  this  thesis  effort  is  not 
unique.  In  fact,  the  simulation  process  outlined  by  A.  Alan  B. 
Pritsker  is  very  much  representative  of  the  process  this  effort 
follows.  Table  II  shows  the  ten  steps  cited  by  Pritsker. 


Table  II. 


The  Simulation  Process  [Pritsker,  1984:10-13]. 


Problem  Formulation 


6 .  Validation 


Mode  1  Building 


Data  Acquisition 


Model  Translation 


5 .  Ver i f i ca  t i on 


7 .  Strategic  and 

Tactical  Planning 

8 .  Exper i men  ta  t ion 

9.  Analysis  of  Results 

10.  Implementation  and 
Documen  ta  t i on 


These  steps  outlined  by  Pritsker  are  not  the  only  approach  to  a 
simulation  thesis.  Shannon  provides  a  similar  list  in  his 
article,  "Simulation:  A  Survey  with  Research  Suggestions" 
[Shannon,  1975:289-290].  Banks  and  Carson  also  discusses  the 
steps  in  the  simulation  process  in  their  text  [Banks  and  Carson, 
1984:11-14].  This  analysis  will  follow  a  process  which  includes 
the  major  elements  found  in  all  of  these  suggested  outlines. 

Problem  Formulat ion/ Background  St  udy.  The  actual  problem 
identification  in  this  study  was  originally  posed  by  the  AFURL. 
The  question  of  what  effect  the  CIS-ISS  would  have  on  the  TACS 
was  a  logical  one  from  the  start.  Although  significant  research 
was  done  regarding  the  methodology  to  be  used,  the  simulation 
approach  was  a  major  consideration  from  the  beginning  owing  to 
the  fact  that  the  AFHRL  preferred  to  have  a  well  constructed 
model  of  the  CRC  at  the  conclusion  of  the  thesis  effort. 

The  relevance  of  this  problem  is  documented  in  Chapter  II. 
The  background  study  of  the  problem  served  several  purposes.  One 
purpose  was  to  familiarise  the  authors  with  the  TACS  operation 
from  the  macro  level  all  the  way  down  to  the  specifications  on 
the  communications  links.  This  knowledge  has  proven  especially 
valuable  in  the  construction  phase  of  the  model.  Another  benefit 
of  the  background  study  was  to  gain  insights  from  past  studies  in 
the  same  subject  area  (the  TACS). 

Da  ta  Collection.  The  main  thrust  of  the  data  collection  has 
been  in  the  area  of  operational  tests  of  the  CIS-ISS.  The 
specific  data  elements  required  pertain  mainly  to  the  arrival 


rates  of  hostile  aircraft  for  a  NATO  type  scenario  and  to  the 
reaction/service  times  of  the  various  operators  within  a  control 
and  reporting  center  or  CRC.  The  first  data  available  came  from 
an  operational  test  of  the  CIS-ISS  at  Eglin  AFB,  FL,  in  May  of 
1985  [Preidis,  1985].  Due  to  the  limited  number  of 
observations  in  some  cases,  this  data  will  need  to  be  checked 
against  other  operational  test  data  as  it  becomes  available. 

The  CIS-ISS  tests  conducted  in  Germany  during  the  fall  of 
1985  may  provide  "good”  data  in  that  the  AFHRL  specified  some 
of  the  data  elements  to  be  collected  [Pre i d i s , 1985 ] . 

Having  a  source  of  data  is  only  the  beginning  of  the  data 
collection  process.  Arranging  or  presenting  this  raw  information 
in  a  useful  form  is  the  next  step.  There  are  many  ways  to 
present  data  for  use  in  a  computer  simulation.  For  example,  the 
time  required  to  identify  a  radar  track  could  be  represented  as  a 
constant  average,  a  table  of  probable  values,  or  a  parametric 
distribution  [Innis  and  Rexstad,  1983:7].  Each  situation  will 
dictate  which  is  the  more  efficient  method  based  on  factors  such 
as  the  underlying  population,  model  sensitivity  to  that 
parameter,  and  data  availablity.  These  particular  issues  are 
explored  further  in  Innis  and  Rextad’s  article  on  model 
simplification  [Innis  and  Rextad,  1983:7-10].  As  a  starting 
point,  all  the  data  was  modeled  as  parametric  distributions. 

The  sensitivity  of  the  model  to  the  inputs  determined  their 


final  form. 


1.  Identify  the  distribution 

-  histograms 

-  distributional  assumption 

2.  Parameter  estimation 

-  sample  mean  and  variance 

-  suggested  estimators 

3.  Goodness-of-f i t  tests 

-  chi-square  test 

-  Ko lomogorov-Smi rnov  (K-S)  test 


is  "particularly  useful  when  sample  sizes  are  small  and  when  no 
parameters  are  estimated  by  the  data  [Banks  and  Carson, 

1984:357]."  Most  of  the  data  requiring  distributional 
description  in  this  effort  fit  the  assumptions  required  for  the 
chi-square  test  (i.e.  the  continuous  distributional  assumption 
and  relatively  large  sample  size).  It  is  also  generally  agreed 
that  a  minimum  expected  frequency  of  3,  4,  or  5  be  used  for  the 
class  intervals  in  a  chi-square  test  [Banks  and  Carson,  1984:350; 
Hines  and  Montgomery,  1980:299].  Although  a  strict  definition  of 
a  "large"  sample  size  does  not  exist,  Banks  and  Carson  suggest 
that  a  for  sample  of  less  than  20,  the  chi-square  test  should  not 
be  used  [Banks  and  Carson,  1984:351].  This  being  the  case,  the 
chi-square  test  was  used  almost  exclusively  in  the  input  data 
analysis  of  this  project.  The  final  distributional  forms  of 
the  input  parameters  can  be  found  by  referring  to  the 
computer  code  in  Appendix  A. 

Mode  1  Cons  t  rue  t ion.  The  actual  building  of  the  computer 
model  proceeded  through  several  different  phases.  The  early 
stages  of  model  building  were  based  on  a  simplified 
conceptualization  of  the  CRC  within  the  TACS.  The  actual  coding 
was  done  entirely  using  the  SLAM  'network'  approach,  with  no 
external  FORTRAN  coding  required.  The  entities  were  defined  as 
radar  tracks  flowing  through  the  network  from  the  track 
initiation  event  to  the  eventual  destruction  of  the  track  if 
identified  as  hostile.  The  arrival  rates  of  the  tracks  and  the 


service  tines  in  the  system  were  bused  on  the  data  received  from 
the  May  '85  operational  tests  of  the  CIS-1SS  at  Eg  l  i  n  AFB.  This 
initial  model  did  not  contain  the  level  of  detail  required  in 
several  areas.  First,  the  data  used  for  the  service  time 
distributions  was  not  considered  adequate  because  of  the  limited 
number  of  observations.  The  modeling  of  the  fighter  and  surface 
to  air  missile  engagements  was  also  limited  to  a  very  low  level 
of  detail.  Although  this  first  cut  at  the  model  provided 
valuable  insight  into  the  inner  workings  of  the  Control  and 
Reporting  Center,  the  authors  felt  that  more  detail  was  required 
in  the  previously  mentioned  areas  to  instill  more  confidence  in 
the  model  output. 

Through  the  process  of  research  and  literature  review,  an 
article  by  Merriman  and  Dowdle  of  ALPHATECI1,  Inc.  provided  a 
comparison  of  two  air  defense  command  and  control  models 
(Merriman  and  Dowdle,  19  8  2  J .  After  several  phone  calls  to 
ALPHATECI1,  it  was  learned  that  the  models  were  being  used  by  the 
Command  and  Control  section  of  the  Foreign  Technology  Division 
(FTD/TQC)  at  Wright  Patterson  AFB.  FTD/TQC  is  using  these  two 
models  in  their  work  on  the  Soviet  Air  Defense  system.  The  two 
models  compared  in  the  article  were  Queuing  Based  (QUEB)  and 
Transient  Air  Defense  Zone  (TADZ).  QUEB  is  an  analytical  queuing 
theory  model  of  a  RED  air  defense  zone.  TADZ  is  a  SLAM,  FORTRAN, 
and  Pascal  based  computer  model  of  the  RED  air  defense  zone  and 
its  response  to  a  BLUE  force  attack.  Through  an  examination  of 
the  documentation  and  computer  code  of  TADZ,  it  was  determined 
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that  several  portions  of  the  model  could  be  adapted  to  model 
the  U.S.  TACS.  TADZ  provides  the  level  of  detail  required 
that  was  missing  in  the  first  attempt  at  modeling  the  CRC. 

The  TADZ  model  runs  on  a  VAX/  11-780  with  a  V'.IS  operating 
system  at  FTD  and  is  completely  compatible  with  the  computer  and 
operating  system  available  at  AFIT.  Any  requests  for  access  to 
the  TADZ  coding  or  documentation  should  be  referred  to  FTD/TQC. 
Amasters  thesis  effort  by  Larson  and  Vane  at  the  Naval 
Postgraduate  School  was  very  helpful  in  providing  an 
understanding  of  the  TADZ  model  [Larson  and  Vane,  1985]. 

The  experience  gained  from  the  first  attempt  at  modeling  the 
system  paved  the  way  for  successful  incorporation  of  the 
appropriate  the  CRC  into  TADZ.  Throughout  the  model  building 
process  care  was  taken  not  to  make  the  common  errors  that  can 
beset  any  model  builder.  Innis  and  Rexstad's  article  on  model 
simplification  techniques  was  very  helpful  in  pointing  out  some 
of  the  possible  dangers  and  in  providing  guidance  for  keeping  the 
model  at  the  appropriate  level  of  detail  [Innis  and  Rextad, 

1983].  Coding  improvements,  logic  analysis,  and  variance 
reduction  are  just  a  few  of  the  efficiency  hints  discussed  in 
this  article  that  were  helpful. 

Appendix  A  contains  the  actual  code  of  the  final  CRC  model. 
For  a  detailed  description  of  the  C RC  model  refer  to  Chapter  IV 


Exper  i  men  ta  1  Des  i  gn.  From  trie  authors'  point  of  view, 

one  of  the  important  reasons  for  planning  or  designing  the 

approach  to  be  taken  in  this  thesis  is  economy  of  effort. 

'licks  states  that  in  the  design  of  an  experiment,  "one  seeks 

to  obtain  the  maximum  amount  of  reliable  information  at  the 

minimum  cost  to  the  experimenter  [Hicks,  1973:2],  Montgomery 

defines  the  statistical  design  of  experiments  as: 

the  process  of  planning  the  experiment  so  that  appropriate 
data  will  be  collected,  which  may  be  analyzed  by  statistical 
methods  resulting  in  valid  and  oDjective  conclusions.  The 
statistical  approach  to  experimental  design  is  necessary  if 
we  wish  to  draw  meaningful  conclusions  from  the  data. 
[Montgomery,  1984:2] 

Montgomery  also  recommends  that  everyone  involved  in  the 
"experiment"  have  a  clear  vision  in  advance  of  what  is  to  be 
researched,  the  type  of  data  to  be  collected,  and  a  general  idea 
of  how  the  data  will  be  analyzed  [Montgomery,  1984:3].  In  Hick's 
text,  Fundamental  Concepts  i n  the  Design  o f  Exper i men t s ,  the 
author  suggests  the  outline  shown  in  Table  IV  as  one  possible 
approach  to  experimental  planning  [Hicks,  1973:4,5]. 

Any  textbook  dealing  with  the  subject  of  experimental 
design  will  have  essentially  the  same  elements  included  in 
Table  IV  by  Hicks.  It  was  decided  to  follow  this  particular 
process  in  the  design  of  the  experiment.  In  reality,  the 
order  of  accomplishment  may  have  varied  slightly  during  the 
process,  but  the  intent  was  to  follow  the  general  guidelines. 


Ta  b 1 e  IV. 


Experimental  Planning. 

I.  Experiment 

A.  Statement  of  problem 

B.  Choice  of  response  or  dependent  variable 

C.  Selection  of  factors  to  be  varied 

D.  Choice  of  levels  of  these  factors 

1.  Quantitative  or  qualitative 

2.  Fixed  or  random 

E.  How  factor  levels  are  to  be  combined 

II.  Design 

'A.  Number  of  observations  to  be  taken 

B.  Order  of  experimentation 

C.  Method  of  randomization  to  be  used 

D.  Mathematical  model  to  describe  the  experiment 

III.  Ana  lysis 

A.  Data  collection  and  processing 

B.  Computation  of  test  statistics 

C.  Interpretation  of  results  for  the  experimenter 


In  the  choosing  of  a  response  variable,  the  early  work  on 
the  basic  CRC  model  was  very  valuable.  The  number  of  hostile 
radar  tracks  that  "get  through"  the  air  defense  net  was  the  first 
response  variable  identified.  The  second  response  variable 
chosen  was  the  number  of  incorrect  identifications  by  the 


"system.''  Keep  in  mind  tnat  the  question  to  be  answered  is 
whether  the  CIS-ISS  will  provide  a  significant  improvement  in  the 
identification  process.  These  two  response  variables  will  be  the 
indicators  of  the  improvement  or  lack  of  it. 

The  process  of  selecting  the  factors  t  o  be  varied  was 
continuous  in  nature.  During  the  model  verification  phase  the 
model's  sensitivity  to  the  input  parameters  was  tested  using 
statistical  comparisons  on  the  mean  response  [Banks  and 
Carson,  1984:Ch  10].  An  example  of  a  factor  that  is  varied 
in  this  analysis  is  the  arrival  rate  of  aircra ft/tracks  into 
the  CRC's  coverage  area.  The  decisions  on  exactly  how  to 
vary  the  different  factors  in  the  model  were  made  based  on 
experience  and  from  data  gathered  in  the  background  study 
pertaining  to  system  performance,  resource  levels,  etc.. 

Determining  the  number  o f  observat i ons  to  be  taken  is  a 
decision  that  can  be  aided  by  statistical  analysis.  The  choice 
of  sample  size  is  a  topic  covered  widely  in  the  literature. 
Montgomery,  Banks  and  Carson,  and  Hicks  all  provide  acceptable 
methods  for  determining  sample  size  for  one,  two,  and  several 
factor  designs  [Montgomery,  1984;  Banks  and  Carson,  1984;  Hicks, 
1973].  Fishman  provides  some  useful  insights  on  the  subject  in 
his  Management  Science  article  on  estimating  sample  size 
[Fishman,  1971:21-38].  The  general  technique  involves  the  use  of 
Operating  Characteristic  Curves  found  in  most  statistical 
analysis  and  experimental  design  texts. 
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As  previously  discussed,  the  thrust  of  the  final  analysis  is 
to  compare  the  system  performance  with  and  without  the  CIS-ISS. 
The  plan  for  making  the  experimentation  "runs"  reflects  this 
fact.  Identical  runs  are  made  with  and  without  the  computer 
aided  identification  feature  and  the  results  (the  response 
variables)  are  tested  for  statistical  difference  or  variance. 

This  leads  the  discussion  into  the  area  of  factorial  design  and 
the  use  of  the  ANOVA  (analysis  of  variance). 

Again,  the  literature  contains  several  texts  and  articles 
dealing  with  ANOVA  and  statistical  analysis  of  the  output  from  a 
simulation  model.  The  following  authors  address  the  subject: 

Law  and  Kelton,  1982;  Hicks,  1973;  Banks  and  Carson,  1984;  and 
Montgomery,  1984  ].  Carson  and  Law  have  written  an  excellent 
article  in  the  Opera  t  i  ons  .le  search  journal  on  the  subject  of 
confidence  intervals  using  the  *  t  *  statistic  and  the  use  of 
blocking  in  factorial  design  [Carson  and  Law,  1979:1011-1025]. 

Another  topic  of  interest  in  experimental  design  is  variance 
reduction.  The  various  "techniques  or  tricks"  in  this  area  are 
meant  to  improve  the  statistical  efficiency  of  the  experiment 
[Banks  and  Carson,  1984:487].  Common  random  numbers  and 
antithetic  random  numbers  are  two  of  the  more  widely  discussed 
methods.  Kleijnen  discusses  these  two  techniques  in  his 
Management  Science  article  [Kleijnen,  1975:1176-1185].  Law  and 
Kelton  devote  an  entire  chapter  in  their  text,  S i mu  1  a  t ion 


■  lode  ling  and  Analysis  [Law  and  Kelton,  1982:Ch  11].  Due  to  the 
complexity  of  the  CRC  model,  a  combination  of  both  the  antithetic 
and  common  random  number  techniques  was  used  in  this  experiment. 

Verification  and  Validation.  As  noted  earlier,  it  is 
important  to  have  a  vision  of  the  experimental  design  prior  to 
performing  the  experiment  itself.  A  great  deal  of  the  previous 
discussion  centered  on  the  statistical  techniques  used  within 
that  design.  An  important  aspect  of  the  design  that  must  be 
remembered  throughout  the  process  is  the  verification  and 
validation  of  the  model  itself.  Verification  can  be  defined  as 
"the  comparison  of  the  conceptual  model  to  the  computer  code  that 
implements  that  conception"  [Banks  and  Carson,  1984:376)].  In 
simpler  words:  does  the  model  perform  as  intended?  Tn  i  s  question 
is  answered  on  a  continual  basis  within  both  the  model 
construction  and  experimentation  phases.  A  common  sense  list  of 
suggestions  for  verification  is  provided  in  chapter  ten  of  Banks 
and  Carson's  book.  These  suggestions  are  "basically  the  same 
ones  any  programmer  would  follow  when  debugging  a  computer 
program"  [Banks  and  Ca rson ,  1 9 8 4  : 3 7 9  ] . 

Validation  is  defined  as  follows: 

the  act  of  determining  that  a  model  is  an  accurate 
representation  of  the  real  system.  Validation  is  usually 
achieved  through  the  calibration  of  the  model,  an  iterative 
process  of  comparing  the  model  to  actual  system  behavior  and 
using  the  discrepancies  between  the  two,  and  the  insights 
gained,  to  improve  the  model.  This  process  is  repeated 
until  model  accuracy  is  judged  to  be  acceptable.  [Banks  and 
Carson,  1984:377] 

One  simple  method  of  validating  a  model  without  using  statistics 


is  the  Turing  test.  The  test  involves  asking  an  '’expert’’  in  the 
field  of  interest  to  distinguish  between  real  world  data  and  the 
output  of  the  model.  If  the  expert  is  able  to  identify  the  model 
output  as  different,  the  model  builder  needs  to  work  on  improving 
the  model.  The  Turing  test  can  be  used  in  an  iterative  fashion 
to  fine-tune  the  model  [Law  and  Kelton,  1932:338;  Banks  and 
Carson,  1984:401]. 

The  method  of  comparing  output  to  real  world  data  can  be 
extended  into  the  realm  of  statistics  through  the  validating  of 
input-output  transformations.  This  is  accomplished  by  running 
the  model  with  certain  input  parameters  and  then  observing  the 
"transformation"  of  these  inputs  into  output  measures  of 
performance.  These  model  output  measures  are  then  compared  to 
data  from  the  actual  system  using  hypothesis  testing  on  the 
difference  in  the  means,  generally  u sing  the  't'  statistic  [Banks 
and  Carson,  1984:392-393],  "A  necessary  condition  for  the 
validation  of  input-output  transformations  is  that  some  version 
of  the  system  under  study  exists,  so  that  system  data  under  at 
least  one  set  of  input  conditions  can  be  collected  to  compare  to 
model  predictions  [Banks  and  Carson,  1984:387]."  The  TAGS  is  an 
existing  system  and  the  data  obtained  from  several  operational 
exercises  is  used  for  comparative  purposes. 

R.G.  Sargent  in  his  article,  "  Verification  and  Validation 
of  Simulation  Models,"  provides  a  list  of  twelve  validation 
techniques  that  can  be  used  to  develope  confidence  in  the  model. 
Table  V  below  is  a  recreation  of  that  list. 
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Table  V. 


Validation  Techniques  [Sargent,  1982: 162-163] . 


1 . 

Face  validity 

t  . 

Comparison  to  other 

mode  1  s 

2  . 

Traces 

8  . 

Historical  data 

3  . 

Historical  methods 

va 1 i da  t i on 

4  . 

Multistage  validation 

9  . 

Predictive  validation 

5  . 

Internal  validity 

10  . 

Event  validity 

6. 

Parametric  variability/ 

11  . 

Graph i c  d i sp lay s  i 

Sens i t i v i ty  ana  lysis 

12  . 

Turing  tests 

A  few  of  the  techniques  listed  have  already  been  discussed  and  a 
thorough  description  of  each  would  not  be  appropriate  here. 

Refer  to  Sargent's  article  for  more  information.  Sargent  also 
includes  an  excellent  bibliography  covering  the  areas  of 
verification  and  validation.  Unfortunately,  there  are  no  current 
"cook  book"  approaches  for  the  validation  of  simulation  models. 

A  combination  of  the  above  listed  techniques  is  generally  used, 
but  the  question  of  which  ones  to  use  is  left  to  the  analyst. 
Sargent  does  suggest  the  use  of  f a c t or- scree n i ng  experiments  in 
the  case  of  large-scale  models  to  reduce  the  number  of  variable 
combinations  to  be  tested  [Sargent,  1982:167].  Pritsker  states  in 
his  text  that  "in  making  validation  studies,  the  comparison 
yardstick  should  be  both  past  system  outputs  and  experiential 
knowledge  of  system  performance  behavior  [Pritsker,  1984:13]." 
Stated  in  laymen's  terms,  validation  tests  are  simply  checks  on 
the  "reasonableness"  of  the  model. 
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As  stated  previously,  a  combination  of  techniques  is 
generally  used  to  verify  and  validate  the  model.  Many  times  the 
cost  and  the  time  available  to  accomplish  these  steps  play  a 
major  role  in  determining  which  technique(s)  to  use  [Banks  and 
Carson,  1984:402;  Sargent,  1982:160].  Again,  the  analyst  or 
model  builder  makes  the  final  decision.  Both  of  the  following 
texts  provide  complete  treatments  of  the  verification  and 
validations  of  simulation  models:  Law  and  Kelton,  and  Banks  and 
Carson  (both  chapter  10). 

Keeping  on  Track 

With  so  many  different  techniques  and  suggestions  to  keep  in 
mind  while  building  the  model  and  performing  the  analysis,  it 
would  be  very  easy  to  stray  "off  course"  during  a  simulation 
effort.  Having  a  good  research  design  and  a  strict  time 
schedule  to  follow  helped  avoid  significant  problems  in  this 
area.  In  Annino  and  Russell's  Interfaces  article,  these 
seven  reasons  are  offered  as  the  most  frequent  causes  of 
simulation  analysis  failure  [Annino  and  Russell,  1981:63]: 

1.  Failure  to  define  an  achievable  goal 

2.  Incomplete  mix  of  essential  skills 

3.  Inadequate  level  of  user  participation 

4.  Inappropriate  levels  of  detail 

5.  Inappropriate  language 

6.  Using  an  unverified  or  invalid  model 

7.  Failure  to  use  modern  tools  and  techniques 


Paying  heed  to  this  list  helped  keep  the  research  effort  on  a 
coarse  toward  successful  completion. 

Summary 

This  chapter  has  described  the  research  design  for  this 
thesis  effort.  A  brief  review  of  the  background  study  of  the 
problem  preceded  a  description  of  the  data  collection  and  model 
construction  processes.  The  experimental  design  was  presented 
along  with  a  discussion  of  the  verification  and  validation 
phases.  Finally,  a  short  section  covering  the  potential  pitfalls 
in  a  simulation  study  was  included  with  the  aim  of  keeping  the 
research  "on  track." 

In  the  following  chapter,  the  CRC  model  will  be  described  as 
it  was  implemented  in  the  TADZ  model.  In  addition,  the  assump¬ 
tions  and  changes  required  to  use  the  TADZ  model  are  highlighted. 


IV.  MODEL  DESCRIPTION 


Introduct  i  on 

As  stated  in  Chapter  III,  this  effort  began  with  a 
simple  simulation  model  of  the  CRC  in  the  SLAM  language.  The 
time  spent  in  building  this  model  was  valuable  in  that  much 
insight  and  understanding  of  the  TACS  operation  was  gained 
through  the  process.  Upon  finding  the  Transient  Air  Defense 
Zone  (TADZ)  model  by  ALPHATECH,  Inc.  available  at  FTD,  it  was 
decided  to  use  the  TADZ  model  to  simulate  the  operation  of 
the  CRC  within  the  TACS.  The  overall  objective  of  the  thesis 
did  not  change:  to  evaluate  the  utility  of  the  CIS-ISS 
within  the  tactical  air  control  system. 

This  chapter  of  the  thesis  will  describe  the  simulation 
model  at  several  levels.  First,  TADZ  will  be  explained  as 
used  by  ALPHATECH  and  FTD.  Secondly,  the  TADZ  model  will  be 
described  as  it  has  been  modified  to  represent  a  U.S. 
tactical  scenario  at  a  basic  level.  Thirdly,  a  central 
European  type  scenario  will  be  explained  as  it  has  been 
implemented  in  TADZ.  The  final  portion  of  the  chapter  will 
list  the  changes  and  adaptations  that  had  to  be  made  in  TADZ 
in  order  to  model  a  tactical  scenario  and  implement  the 
identification  feaure  required  to  analyze  the  CIS-ISS. 


Description  o  f  TADZ. 

The  TADZ  model  was  developed  by  ALPHATECH  to  model  the 
command,  control,  and  communication  process  (C ^ )  within  the 
Soviet  air  defense  system.  Essentially,  the  purpose  of  the 
Soviet  air  defense  system  is  the  same  as  the  TAC3,  that  being 
to  provide  a  means  of  detecting,  reporting,  and  prosecuting 
hostile  air  threats.  In  more  analytical  terms,  "the  goal  of 
the  air  defense  C  ^  system  is  to  maximize  the  use  of  scarce 
resources  in  bringing  them  to  bear  against  penetrating 
threats  [Larson  and  Vane,  1985:24]." 

In  TADZ,  the  enemy  penetrators  are  the  customers  or 
entities  flowing  through  the  air  defense  zone  and  the  defense 
assets  (radars,  command  centers,  SAM's,  and  fighters)  are  the 
servers.  Since  TADZ  is  essentially  based  on  queuing  theory, 
there  are  many  factors  within  the  C3  system  that  can  be 
anlayzed.  Response  (service)  times,  arrival  rate  of  the 
threats,  and  the  available  resources  to  prosecute  the 
penetrators  are  just  a  few  of  the  factors  that  can  be  varied 
and  analyzed  using  the  TADZ  model.  TADZ  not  only  models  the 
"external"  process  of  detecting  the  penetrators  and 
prosecuting  them,  but  it  also  models  the  "internal"  decision 
making  or  command  and  control  (C2)  process  within  the  air 
defense  system.  Some  examples  of  the  servers  in  the  internal 
system  are  the  communications  links  and  the  truck  report  .pa 
selection  which  operate  during  the  transfer  of  information  or 


messages  between  the  elements  of  tne  system  [Larson  and 
Vane,  1985:2  6  —  2  7  J. 

The  overall  emphasis  in  designing  TADZ  was  "on  message 
routing  doctrine  and  C**  decision  making  logic,  while 
providing  enough  detail  in  the  surveillance  and  prosecution 
modeling  to  capture  the  essential  aspects  of  these  phases  of 
air  defense  [Merriman  et  al,  1984:14]."  Because  of  this 
emphasis  in  the  building  process,  the  TADZ  model  was  well 
suited  for  investigating  the  CIS-1SS  question  in  a  tactical 
environment.  Despite  the  differences  between  the  Soviet  and 
U.S.  command  and  control  doctrine,  this  model  can  represent 
the  "network"  connectivity  in  a  myriad  of  ways.  In  short, 
the  TADZ  model  is  very  flexible. 

Resource  Kequ i remen  t  s.  "TADZ  is  implemented  using 
FORTRAN-77  and  the  simulation  language  SLAM  (simulation 
language  for  alternative  modeling)  [Merriman,  1985:52]"  The 
actual  FORTRAN  coding  was  developed  on  a  VAX  11-780  using  the 
VMS  operating  system.  The  files  necessary  to  run  TADZ 
require  approximately  4.5  megabytes  of  disk  space  just  for 
storage  of  the  working  files.  Executing  the  model  requires 
approimately  10  megabytes  of  virtual  address  space. 

The  FORTRAN  coding,  which  is  the  bulk  of  the  TADZ  model, 
consists  of  over  280  FORTRAN  files.  Each  of  these  files  is  a 
subrout. ne  that  is  compiled  into  a  larger  object  file  which 
makes  up  the  actual  executable  code.  Changes  in  the  decision 


logic  required  modifying  a  few  specific  subroutines  and  the 
interfacing  subroutines  (those  files  that  call  or  are  called 
by  the  changed  subroutine).  [ Merr i man,  1985:2  —  3  J 

TADZ  Mode  1 i ng  Approach 

The  TADZ  modeling  process  can  be  broken  down  into  the 
following  catagories  of  "s ub-mode  1  s " :  situational  tmodels, 
organizational  models,  equipment  models,  process  models  and 
doctrinal  models  [Larson  and  Vane,  19S5:J9j. 

The  situational  models  specify  the  geography  of  the 
scenario  and  the  threat.  The  geography  is  detailed  through 
such  things  as  control  boundries  and  the  terrain.  The  threat 
is  modeled  through  the  description  of  the  individual  threat 
types,  including  speed,  radar  cross-section,  offensive  and 
defensive  capabilities  and  the  flight  path  used  in  the 
scenari o . 

The  organizational  models  describe  the  organization  of 
the  C*  structure  and  the  associated  connectivity  between  the 
various  nodes  of  the  network.  The  equipment  sub-models 
include  the  modeling  of  the  radars  through  the  use  of  the 
radar  range  equation  and  the  description  of  the  threat 
prosecution  assets  (fighters  and  SAM's). 

At  each  control  or  surveillance  node,  the  processing 
time  for  information  flow  is  modeled.  Communication  between 
the  nodes  of  the  system  are  assumed  to  be  perfect  in  most 


iii  piemen  tut  ions  of  l'ADZ  thus  far,  but  the  model  does  have  the 
capauility  to  describe  less  than  perfect  communication 
[Larson  and  Vane,  1985:40 j. 

The  process  models  include  the  elements  of  detection, 
weapons  control,  and  weapon  allocation  procedures.  Also 
considered  are  such  factors  as  equipment  servicing  to  include 
fighter  refueling  and  re-arming,  as  well  as  the  reloading  of 
the  surface  to  air  missiles  (Larson  and  Vane,  1985:40]. 

As  stated  previously,  TADZ  is  a  model  of  a  Soviet  air 
defense  system  and,  as  such,  models  the  network  with  Soviet 
doctrine  throughout.  Fortunately,  TADZ  is  flexible  enough 
through  its  input  files  that  any  specific  differences  in 
areas  such  as  command  policies  can  be  explicitly  treated. 

The  latter  portion  of  this  chapter  will  explain  the 
modifications  that  had  to  be  made  to  model  the  identification 
or  CIS-ISS  function  for  this  thesis.  The  reader  is  referred 
to  the  TADZ  user's  guide  for  a  more  detailed  description  of 
the  above  elements  [Merriman  et  al,  1984).  Appendix  C 
contains  a  user's  guide  for  the  TADZ  implementation  as 
constructed  for  this  thesis  effort. 

iMode  1  1  mp  1  emen  ta  t  i  on 

Thus  far  in  this  description  of  the  model,  the  general 
elements  of  TADZ  have  been  discussed.  An  overview  of  the 
implementation  or  execution  phases  might  be  helpful  at  this 
point.  There  are  three  logical  phases  to  discuss  in  the 


implementation  of  the  model:  preprocessing,  simulation,  and 

postprocessing.  The  TADZ  User's  Guide  gives  the  following 

description  of  these  phases: 

In  TADZ,  preprocessing  and  simulation  are  performed  in 
the  main  execution  module,  while  postprocessing 
capability  is  provided  in  an  independent  execution  file. 
The  main  execution  module  contains  a  large  number  of 
FORTRAN  modu 1 es , 1  i  nked  to  the  SLAM  simulation  language. 

A  substantial  amount  of  preprocessing  is  done  before  the 
simulation  of  scenario  events  begins.  When  simulation 
starts,  control  passes  to  SLAM,  which  selects  the  next 
action  to  be  per  f  ormed....by  maintaining  a  calendar  of 
simulation  events  that  have  previously  been  scheduled. 
Pos tprocess i ng  is  done  in  a  module  written  in  FORTRAN 
and  PASCAL,  which  contains  menu  structures  like  those 
used  in  gUEB.  The  postprocessor  reads  raw  data  files 
produced  by  TADZ  ,  and  provides  menus  that  allow  the 
user  to  derive  stastistics  from  this  raw  data  and 
selectively  display  these  statistics.  [Merriman  et  al, 
1984:18] 

Figure  4  displays  the  major  elements  of  TADZ. 

The  initial  execution  of  the  model  begins  by  reading  the 
user  input  data  files  describing  the  scenario  to  be 
specifically  modeled  during  that  run.  These  files  include 
order  of  battle  information  for  both  "sides",  specifications 
on  the  radars,  aircraft,  and  missiles,  and  the  description  of 
the  connectivity.  Again,  Appendix  C  contains  more 
detailed  implementation  information  on  the  construction  of 
these  data  files.  Chapter  II  of  the  TADZ  User's  Guide  goes 
into  much  more  detail  on  the  model  structure  and 
implementation  [Merriman  et  al,  1984:18-43]. 


TADZ  Network  Connect i v i ty 

The  network  configuration  modeled  in  TADZ  is  quite 
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adaptive  to  different  scenarios.  Although  originally  set  up 
to  model  the  Soviet  command  network,  it  was  easily 
reconfigured  to  represent  the  configuration  of  a  CKC 
within  the  TACS.  The  TADZ  documentation  uses  some 
nomenclature  that  may  be  confusing,  so  the  following 
discussion  will  clarify  and  explain  the  labeling  conventions 
used  in  TADZ  along  with  a  simple  description  of  theCRC 
network  and  connectivity  as  it  is  represented  by  TADZ. 

Figure  5  illustrates  the  TADZ  representation  of  the 
Soviet  style  C**  network.  The  labels  on  the  various  nodes  in 
this  network  correspond  to  specific  functions  and  locations 
within  the  surveillance  and  control  structure.  As  depicted  in 
the  diagram,  the  flow  of  information  follows  a  "he i rarch i ca 1” 
format.  The  K°  represents  either  an  acquisition  or 
surveillance/early  warning  radar.  An  S°  is  defined  as  a 
filtering  and  reporting  center.  The  S1  represents  a  sector 
filter  center  one  level  above  the  S°  in  the  hierarchy.  The 
top  level  of  the  surveillance  portion  of  the  network  is 
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modeled  by  the  S  4  node  and  is  known  in  Soviet  terminology  as 
a  zone  filter  center.  The  next  node  in  the  network  is  the  C2 
node  which  is  the  top  level  of  the  command  structure  or  the 
air  defense  weapons  operations  center  (ADWOC).  The  next 
level  down  in  the  command  structure  is  the  reg i men ta 1 /br i gade 
command  post  or  C*  node.  The  bottom  level  in  the  command 
hierarchy  is  represented  by  the  C°  node  or  GCI/Fire  Control 
Post.  The  Cu  node  "controls"  the  fighter  interceptor  and  SAM 


Figure  G.  CRC  as  Represented  by  TROZ. 


into  a  detailed  description  of  the  reponsibilities  of  eaon  of 
tnese  nodes  as  they  exist  in  the  Soviet  air  defense  system,  a 
simple  network  model  of  the  CRC  will  be  described  as  it  is 
represented  by  the  TADZ  model.  Figure  6  is  a  network  diagram 
of  the  CRC  within  the  U.S.  tactical  air  control  system. 

Since  this  thesis  is  modeling  a  tactical  air  defense 
system,  the  more  detailed  description  is  included  here  as  it 
relates  to  the  functions  and  responsibilities  within  the 
TACS.  Tne  U.S  and  Soviet  systems  are  similar  in  that  the 
same  type  of  air  defense  decisions  and  actions  must  be  made, 
but  the  location  of  the  nodes  and  the  levels  at  which  the 
decisions  are  made  are  generally  quite  different.  Table  VI 
explains  the  functions  and  locations  of  the  C3  nodes  for  the 
CllC/TACS  as  represented  with  the  TADZ  nomenclature. 

Fora  review  of  the  various  functions  within  the  CRC , 
refer  to  TACK  55-44  or  the  background  section  of  Chapter  1 
[TACK  55-44,  1985].  The  detailed  specifications  for  all 

these  nodes  are  listed  in  the  input  files  for  TAOZ.  Appendix 
13  gives  instructions  and  examples  on  how  to  build  the 
required  files  for  implementing  TADZ  with  a  particular 


scenario. 
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TADZ  Description  of  the  TAGS. 
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scenario  //as  required  to  accurately  model  the  TACS  in  a  valid 
setting.  This  study  as  described  in  Chapter  1,  is  based  on  u 
Central  European  scenario  with  a  massive  conventional  attack 
from  the  WARSAW  Pact  forces.  The  air  defense  in  this  region 
is  essentially  divided  into  two  zones  (4  ATAF,  2  ATAF).  The 
scenario  chosen  for  this  simulation  models  a  "generic"  U.S. 
air  defense  zone  [Spaeth,  1985].  Figure  7  is  a  depiction  of 
this  scenario.  Again,  this  is  a  generic  scenario  and  future 
users  could  easily  build  a  simpler  or  more  advanced 
simulation  by  simply  rebuilding  the  TADZ  input  files.  This 
scenario  includes  essentially  one  early  warning/ground 
controlled  intercept  (EW/GCI)  radar,  three  combat  air  patrols 
(CAP)  points  (C0FI1  -  C0FI3),  four  SAM  batteries  (with 
associated  equipment,  Mil  -  MI4),  and  one  CRC.  The  lethal 
engagement  zones  for  the  SAM  batteries  are  indicated  by  the 
hashed  circles.  The  TADZ  network  representation  is  much  more 
complicated  than  the  simple  CRC  model  described  earlier. 
Figure  8  is  the  network  depiction  of  the  final  CRC  scenario. 

As  stated  earlier,  this  scenario  could  be  enhanced 
fairly  easily.  AFUUL's  envisioned  use  of  the  model  should 
not  require  any  drastic  changes  in  the  scenario  or  the  other 
parameters  within  the  FORTRAN  coding  of  TADZ.  The 
information  in  Appendix  13  will  enable  the  user  to  make  the 
required  changes  to  the  scenario.  Any  deeper  excursions  into 
coding  changes  would  require  a  more  in-depth  study  of  I’ADZ 


Thesi 


•ind  its  implementation.  Trie  i.Vi'A  instruction  manuaJs  (Voi  I, 
II,  III)  available  througn  FTD/ P  jC  or  ALP'IATKCil,  Inc.  are 
recommended  for  this  purpose.  Tne  next  section  of  t  ti  i  s 
chapter  will  deal  with  the  FORTRAN  changes  required  in  TADZ 
to  model  the  identification  function  in  the  tactical 
scenario. 

TADZ  Mod i f i ca  t i ons 

In  order  to  implement  the  functioning  of  the  CIS-ISS  in 
the  TADZ  model,  three  major  modifications  were  required.  The 
three  modifications  are  required  to  emulate  the  realistic 
flexibility  of  operations  available  in  the  TACS  and  not 
available  in  the  TADZ  model.  The  three  operational  functions 
not  in  the  TADZ  model  are:  (1)  the  ability  to  decide  not  to 
prosecute  a  penetrator,  (2)  the  ability  to  distinguish  among 
penetrators  (friend  from  foe),  and  (3)  the  ability  to  perform 
an  identification  intercept. 

First,  the  model  needed  the  capability  to  not  prosecute 
a  penetrator.  The  existing  TADZ  logic  assumed  that  all  radar 
detections  were  hostile  aircraft  attempting  to  penetrate  the 
air  defense  zone.  Since  all  penetrators  were  assumed  to  be 
hostile,  the  air  defense  system  made  an  attempt  to  destroy 
each  penetrator  with  the  assets  available.  This  assumption 
is  not  valid  for  the  scenario  employed  to  test  the  CIS-ISS. 
The  CIS-ISS  was  tested  for  its  ability  to  assist  in  the 
identification  process.  This  identification  process  will  not 


only  distinguish  friend  from  foe  but  will  also  provide  the 
probable  type.  Tne  system  needs  tne  aoility  to  not 
prosecute  a  detected  aircraft  when  the  aircraft  is  identified 
as  friendly  or  for  some  other  command  decision.  This 
selective  prosecution  capability  was  not  provided  in  the 
original  TADZ  coding. 

The  second  major  modification  of  TADZ  required  a  change 
to  the  model  so  that  an  identification  code  could  be  attached 
to  each  penetrator.  This  modification  reflects  the 
identification  friend  or  foe,  selective  identification 
feature  ( IFF/SIF)  present  in  the  existing  TAGS.  The 
previously  modified  selective  prosecution  feature  could  then 
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be  selected  based  on  the  information  contained  in  the 
identification  code.  The  actual  identification  codes  used  in 
the  model  are  detailed  below. 

The  third  feature  added  to  the  TADZ  model  was  the 
identification  intercept.  Based  on  the  existing  operating 
orders  or  the  rules  of  engagement,  a  penetrator  may  require  a 
visual  identification  prior  to  execution  authorization.  This 
type  of  execution  requites  the  deliberate  withholding  of  the 
authorization  for  missile  engagement  and  the  explicit  use  of 
fighters.  In  addition,  the  fighters  are  restricted  from 
using  long  range  weapons  against  the  penetrator  prior  to  the 
pilot  making  a  visual  identification  of  the  penetrator. 
Penetrators  which  cannot  be  specifically  identified  as 


friend,  foe  or  neutral  require  this  type  of  identification 
i  n  t  e  r  c  e  o  t  . 

Additionally,  the  TADZ  model  used  the  uniform 
distribution  to  model  the  average  service  times  for  message 
processing  at  the  TADZ  nodes.  Since  the  analysis  of  the 
Eglin  test  data  showed  that  these  processing  times  actually 
fit  the  exponential  distribution,  the  message  processing  was 
changed  from  uniform  to  exponential  in  the  subroutine 
SERVTIME. FOR. 

TADZ  Entities.  Externally,  the  model  treats  the 
penetrators  entering  the  air  defense  zone  as  the  customers  to 
be  served.  Internally,  the  entities  that  flow  through  the 
TADZ  model  are  the  command  and  control  messages  which  would 
normally  be  distributed  through  an  air  defense  system.  The 
processing  of  the  messages  within  the  SLAM  network  represents 
the  servicing  of  the  penetrator  customers.  In  order  to 
change  the  TADZ  network  to  implement  the  modifications 
required  for  the  CIS-ISS  function,  two  methods  could  have 
been  used.  First,  the  messages  entities  could  have  been 
modified  to  include  the  identification  of  the  penetrator. 
Secondly,  the  processing  of  the  messages  could  have  been 
changed  so  an  identification  code  would  indicate  whether  the 
penetrator  was  friendly  and  whether  or  not  the  air  defense 
system  should  prosecute  the  detected  aircraft. 

Because  the  timing  in  the  TADZ. model  is  based  on  time 
elapsed  while  processing  the  messages  generated  by  the 


various  nodes  in  the  air  defense  system,  it  ./as  important  to 
ensure  that  the  selective  prosecution  feature  did  not  affect 
the  normal  message  flow.  For  instance,  just  because  a 
penetrator  was  identified  as  friendly  does  not  mean  that  the 
messages  concerning  the  aircraft  could  be  eliminated  from  the 
system.  In  fact  it  is  conceivable  that  the  processing  load 
for  messages  on  friendly  aircraft  could  interfere  with  the 
message  processing  for  the  hostile  aircraft.  Therefore,  in 
order  to  preserve  the  current  flow  of  messages,  the  selective 
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prosecution  feature  was  implemented  at  the  last  processing 
node  possible. 

Selective  Prosecu t i on 

The  selective  prosecution  feature  was  implemented  in  the 
following  manner.  The  TADZ  logic  requires  two  message  events 
to  be  true  before  an  execution  node  (fighter  or  missile  C°) 
will  prosecute  a  penetrator.  The  first  message  the  Cu 
prosecution  node  checks  for  is  the  radar  detection  report. 
TAUZ  logic  requires  that  each  individual  C°  execution  node 
have  a  detection  report  from  an  S  ^  node  that  is  directly 
connected  to  the  C1^  node.  The  detection  reports  routed  via 
the  surveillance  side  of  the  air  defense  system  are  not 
sufficient  for  prosecution,  the  report  must  be  direct  from 
the  S°  to  the  C®.  Tne  second  message  event  required  prior  to 
initiating  a  prosecution  of  a  penetrator  is  an  assignment  (or 
alert)  message.  In  other  words,  the  surveillance  section 


needs  to  detect  the  hostile  penetrators  and  identify  them  as 
hostile.  Then,  the  weapons  control  side  of  the  air  defense 
system  will  make  the  decision  as  to  which  weapons  controller 
(working  a  specific  CAP  point)  or  Hawk  missile  battery  will 
engage  the  penetrator.  When  both  (detection  and  assignment) 
messages  are  present  at  a  node,  TAL)Z  then  'matches'  the 
detection  and  assignment  messages  and  attempts  to  prosecute 
the  penetrator  if  the  assets  are  available.  For  this  reason, 
the  COMATCH  subroutine  was  modified  to  not  file  detection 
reports  at  C11  nodes  for  selected  penetrators  based  on  their 
identification  code. 

CO MATCH.  The  actual  FORTRAN  selective  prosecution  code 
modifications  made  to  TADZ  were  done  in  the  FORTRAN 
subroutine  called  COMATCH. FOR.  It  is  in  this  subroutine  that 
the  system  checks  to  see  if  both  types  of  the  required 
messages  for  prosecution  exist  at  the  specified  C°  node.  The 
subroutine  returns  a  logical  value  of  true  or  false  for  the 
detection  and  assignment  messages  based  on  the  status  of  the 
messages  waiting  for  processing  at  the  node.  To  avoid 
affecting  normal  message  processing  of  TADZ,  the  messages 
themselves  were  not  changed.  Instead,  the  i den t i f i ca t i on  of 
the  penetrator  is  checked  to  see  if  the  identification  does 
not  require  prosecution  (ID  code  5  or  higher).  If  the 
penetrator  does  not  require  prosecution  the  single 
consolidated  assignment  message  produced  by  COMATCH  is  not 
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()  laced  in  an  assignment  queue.  However,  the  penetrutor  is 
still  reported  througn  the  surveillance  side  of  the  CHC. 

This  surveillance  report  will  ensure  that  event  though  the 
system  cannot  prosecute  the  penetratore,  the  model  still 
maintains  the  penetrator  in  the  target  data  base. 

An  IF  THEN  statement  checks  the  identification  code 
attached  to  the  penetrator  and  fails  to  determine  a  queue  for 
the  assignment  message  at  the  for  selected  values  of  the 
identification  code.  The  following  identification  codes  were 
used  in  the  COMATCH  subroutine: 

1  =  Hostile  identified  as  Unknown 

2  =  Friendly  identified  as  Unknown 

3  =  Freindly  identified  as  Hostile 

4  =  Hostile  identified  as  Hostile 

5  =  Friendly  identified  as  Friendly 

6  =  Hostile  identified  as  Friendly 

7  =  Ueliberate  non  prosecution 

8  =  New  code  for  unknown  friendly 

If  the  identification  code  is  5,  6,  7,  or  8,  the  COMATCH 
subroutine  does  not  place  the  assignment  message  in  a  queue 
which  would  enable  execution.  Since  the  added  code  is  at  the 
end  of  the  subroutine,  normal  message  processing  has  already 
been  accomplished.  The  failure  to  place  the  assignment 
message  in  a  queue  only  prevents  the  Cu  node  from  actually 
beginning  prosecution  on  selectively  identified  aircraft. 
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Identification  Fea  t  ure 

In  order  for  the  selective  prosecution  feature  to  work, 
the  individual  penetrators  should  have  the  identification 
code  embedded  in  the  message  entities  that  flow  through  the 
TADZ  network.  However,  the  queues  that  represent  the  air 
defense  system  nodes  are  based  on  the  different  penetrator 
types.  The  messages  which  are  to  be  processed  are  placed  in 
the  queues  based  on  whether  the  messages  are  first  detection 
reports  or  continued  reports.  Thus,  the  number  of  queues 
attached  to  each  node  which  represents  a  portion  of  the  air 
defense  system  is  eight.  There  are  two  queues  for  each 
penetrator  type  (maximum  of  4),  one  for  first  reports  and  one 
for  continued  reports.  The  creators  of  TADZ  also  allowed  a 
ninth  node  in  the  system  for  expansion.  Since  the 
identification  codes  are  not  limited  or  tied  to  the 
penetrator  type,  the  queues  were  not  used  to  manipulate  or 
use  the  identification  code.  In  addition,  the  computing 
overhead  that  would  be  required  to  pass  the  attribute  array 
each  time  a  Cu  node  evaluates  a  penetrator  would  make  such  a 
method  of  implementing  the  identification  feature  cost 
prohibitive  in  execution  time. 

The  TADZ  FORTRAN  code  provides  a  means  to  collect  the 
data  on  the  penetrators  as  they  progress  through  the  system. 
Tne  penetrators  and  their  i den t i f i ca t i on  codes  are 
initialized  in  the  PLNINT.FOR  subroutine  and  then  passed  to 
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each  routine  that  needs  the  Jata  in  the  PEN  1 l)K, : 
block  definition.  The  suoroutine  that  prints  tne  final 
output  file  is  PEINTPEN.  FOE.  Tnis  subroutine  prints  output 
which  contains  the  penetrator  number,  the  penetrator  path, 
and  the  times  of  first  detection,  first  assignment,  first 
engagement,  destruction,  and  identification  code.  The 
following  paragraphs  describe  the  changes  made  in  each  of 
these  subroutines. 

PEN  I  DENT.  1 NC.  The  labeled  common  block  contains  the 
identification  information  on  the  penetrators.  The  specific 
identification  code  can  be  referenced  using  the  array 
PEN_ID£NT  (I).  The  index  of  the  array  PEN_I DENT  is  the 
penetrator  number  so  that  each  value  of  the  array  is  tied  to 
a  specific  penetrator. 

PEN  1  NT.  FOR.  The  FORTRAN  subroutine  PEN  I  NT.  FOR  actual  In¬ 

sets  the  i den t i f i ca t i on  codes  used  in  the  model.  The 
identification  code  is  determined  using  a  random  draw  from  a 
uniform  distribution.  The  identification  code  is  then  set 
using  IF  THEN  ELSE  statements  and  predetermined  probability 
values.  The  different  levels  or  capabilities  of  the  OIS-ISS 
to  perform  the  identification  feature  can  then  be  varied  for 
analysis  by  changing  the  probabilities  in  this  subroutine. 
Figure  9  shows  a  decision  tree  for  one  set  of  factor  levels 
for  accuracy  (.99)  and  capability  (.06).  Recall  that  10 
percent  of  the  penetrators  were  assumed  to  be  friendly,  and 
the  remaining  90  percent  were  hostile. 


Figure  9.  Identification  Probabilities. 


PR  I NTPKN.  FOR.  Tn  I  s  subroutine  provides  the  output  that 
is  used  by  TADZ  instead  of  the  SLAM  statistical  collections. 
Tn i s  output  file  was  changed  to  provide  a  means  of  tracking 
the  identification  code  that  was  generated  in  PEN' I  NT. FOR. 

This  also  allows  the  analyst  to  verify  that  the  appropriately 
coded  penetrators  are  not  executed.  The  code  changes  added 
the  penetrator  identification  code  to  the  existing  output 
file  for  verification  by  the  analyst. 

lden  t i f i ca  t i on  Intercept 

Emulating  an  identification  intercept  within  the  TADZ 
model  required  the  ability  to  designate  the  penetrator  for 
execution  by  fighters  only.  In  addition,  the  fighters  must 
not  use  long  range  weapons,  rather  they  must  conduct  a  visual 
intercept.  Once  identified,  the  model  needed  the  ability  to 
either  abort  the  intercept  or  destroy  the  penetrator  when  the 
visual  identification  was  completed. 

The  actual  code  changes  required  to  implement  an 
identification  intercept  was  made  in  three  files.  The 
SOD l  SP TCP.. FOR  was  further  modified,  along  with  the 
subroutines  which  control  the  release  of  long  range  and  short 
range  weapons  (  LODGF I  iiE.FOK  and  SHOUTF  I  KE.  FOR) . 

COiMATCIl. FOR.  The  coding  in  this  subroutine  was  given  an 
expanded  IF  THEN  structure  to  sequence  through  both  the 
identification  code  and  the  node  labeling  structure  to  ensure 
that  a  valid  assignment  message  is  placed  only  in  the  message 


processing  queue  for  C^'s  identified  ns  a  fijhter  C° 


In  e 


actual  coding  assumes  foreknowledge  of  the  number  of  fighter 
Cus  in  the  scenario.  Changes  in  the  number  of  fighter  C^s 
would  require  changes  to  the  code  and  recompiling  of  the  TADZ 
model.  See  appendix  B  for  the  detailed  procedure  to 
accomplish  this  straightforward  modification  and  a  listing  of 
the  actual  code  changes  implemented. 


vali  da  led  Tor  use  at  FTD.  It  is  currently  be  in;*  used  in 
studies  conducted  at  FTD.  Therefore,  if  tne  code  changes  can 
be  shown  to  have  no  effect  on  the  original  processing  of  the 
model,  the  model  is  still  a  valid  model.  In  addition,  the 
output  results  and  penetrator  prosecution  were  reviewed  by 
air  defense  experts  at  the  Human  Resources  Labratory  for  face 
validity.  No  obvious  discrepancies  were  detected. 

Ver i f i ca  t i on.  Mach  change  of  the  TADZ  FORTRAN  codin; 
needed  to  be  checked  to  ensure  the  original  message 
processing  was  not  affected  by  the  coding  changes  added  for 
the  identification  feature.  The  code  was  verified  by 
comparing  the  following  test  cases  against  a  base  case 
(before  any  code  changes)  running  identical  scenarios  with 
changes  only  in  the  identification  codes  used.  First,  all 
penetrators  were  initialized  with  a  friendly  identification 
code  to  ensure  that  none  of  the  penetrators  were  attacked. 

All  the  penetrators  passed  through  the  system  without  being 
assigned  to  a  ClJ  for  prosecution  while  they  were  still 
detected  at  the  original  tines  reported  in  the  base  case. 
Second,  all  the  penetrators  were  initialized  with  an 
unknown /hostile  identification  code  to  ensure  that  only  FI 
C  .s  attack  the  penetrators.  While  the  assignment  and 
destruction  times  were  different,  this  was  to  be  expected  as 
the  surface  to  air  missile  systems  were  not  used.  Next,  the 
identification  code  was  changed  to  unknown  friendly.  As 
expected,  the  detection  and  assignment  times  reported  by  TADZ 


were  the  same  as  in  tne  second  ease.  The  fourth  ease 
consisted  of  assigning  all  hostile  identification  codes  to 
the  penetriiors.  Since  all  of  the  penetrators  were 
identified  as  hostile,  the  detection,  assignment,  and 
destruction  time  should  be  identical  to  the  base  case  -- 
which  they  were.  Since  there  was  no  reported  differences  in 
the  TADZ  output  between  the  original  coding  and  the  modified 
coding,  the  code  changes  were  verified  as  having  not  adversly 
modified  the  original  TADZ  message  processing.  Thus  the 
model  changes  have  not  affected  the  validity  of  the  original 
model  . 

Summary 

Chapter  IV  has  provided  a  brief  overview  of  the  TADZ 
model  as  provided  by  the  Foreign  Technology  Division.  A 
description  of  the  available  system  nodes  and  their  use  in 
representing  the  tactical  control  system  processes  has  also 
been  explained.  In  addition,  the  required  modifications  to 
implement  a  selective  prosecution  function,  an  identification 
function,  and  an  identification  intercept  feature  in  the  TADZ 
model  were  described.  The  detailed  files,  code  changes,  and 
user  manuals  required  to  implement  the  TADZ  model  are 
contained  in  appendices  A,  H,  and  C.  A  brief  description  of 
the  verification  and  validation  procedures  was  also 
described.  In  the  next  chapter  we  will  provide  a  detailed 
description  of  the  experimental  design  and  the  various  input 


levels  used  for  data  collection.  A  screening  analysis  will 
identify  which  factor  levels  have  significant  effects  on  the 
model.  An  analysis  of  the  effects  due  to  changes  in  the 
input  levels  will  also  be  presented. 


V.  ANALYSIS  OF  JiESULTS 


Introduction 

This  chapter  des'’  ibes  and  explains  the  results  of  the 
experimentation  with  the  modified  TADZ  model.  The 
experiments  were  chosen  to  answer  the  research  question  as  to 
whether  or  not  the  CIS-ISS  would  be  a  valuable  aid  i  a  the 
identification  process  within  the  CRC  and  TAGS.  The 
experimental  design  will  be  reviewed,  the  measures  of  merit 
restated,  and  the  major  findings  will  be  discussed.  Some 
sensitivity  analysis  was  accomplished  along  with  some 
excursions  from  the  original  scenario.  These  will  be 
included  at  the  end  of  the  chapter  along  with  an 
interpretation  of  the  experimental  results  relutive  to  the 
research  question. 

Factors  i n  the  Ana  lysis 

With  such  a  complicated  simulation  model  there  were  many 
input  variables  to  consider  as  factors  for  the  experiment. 
Several  of  these  variables  such  as  number  of  fighter 
interceptors,  number  of  SAM's,  types  of  penetrating  aircraft, 
and  the  routing  of  the  penetrators  were  considered  to  be 
scenario  dependent  and,  thus,  eliminated  from  the  list  of 
factors  to  be  varied  by  using  a  fixed  scenario.  Since  the 
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1.  Capabi  1  i  ty 
(percent  unknown ) 

2.  Accuracy 

( percent  ) 

3.  Identification 
Time  (seconds) 


restrictions  on  t  a  e  anility  of  tne  air  defense  systeri  to 
select  the  appropriate  asset  for  prosecution,  an  unknown 
level  of  "one  out  of  ten"  was  a  reasonable  worst  case.  The 
level  was  increased  by  4  percent  in  two  increments  to 
increase  the  capability  until  the  system  was  five  times 
better,  or  one  out  of  fifty.  The  system  could  provide  a 
specific  identification  code  9U,  94,  and  98  percent  of  the 
times  respectively.  These  levels  are  set  in  the  PEN  I  NT.  FOR 
subroutine  of  the  TAL)Z  code.  (See  Appendix  A  for  the 
implementation  of  the  levels  used  in  the  experiment.) 

Accuracy.  The  accuracy  of  the  identification  was 
another  important  factor  to  consider.  It  should  be  clear 
that  the  ability  to  identify  foe  from  friend  is  a  critical 
and  highly  desirable  characteristic  of  an  identification 
system.  The  initial  estimates  on  CIS-ISS  performance 
advertise  a  99  percent  accuracy  [Perini,  1985:81]  Given  a 
detection,  the  system  is  reportedly  capable  of  identifying 
the  correct  type  of  the  aircraft  99  percent  of  the  time. 

This  variable  is  also  set  in  the  PENINT.FOK  subroutine  in 
TADZ.  Using  the  advertised  accuracy  of  CIS-ISS  as  an  upper 
bound,  the  follow  in  >j  levels  were  chosen  to  provide  a  wide 
range  of  operational  conditions:  low  =  80  percent,  medium  = 
9(J  percent,  and  high  =  99  percent.  These  levels  were 
considered  to  reasonably  cover  the  possible  accuracy  range  of 
both  the  CIS-ISS  and  the  manual  systems. 
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1  d  e  n  t  i  1'icat  ion  Time.  fne  final  level  chosen  for  the 
analysis  was  identification  time.  One  of  the  perceived 
advantages  of  the  automated  system  over  the  manual  system  is 
the  savings  in  time  through  a  faster  identification.  One  of 
the  difficulties  in  choosing  levels  for  this  factor  stems 
from  the  lack  of  unclassified  data  and  also  the  lack  of 
operational  tests  conducted  at  a  threat  level  high  enough  to 
simulate  the  maximum  wartime  system  load.  The  higher 
(slower)  limit  for  this  factor  was  considered  to  be  112 
seconds  per  track.  This  level  is  based  on  data  reduced  from 
the  CIS-ISS  operational  test  at  Eglin  A  F II  in  via  y  of  1984 
[Preidis,  1985].  The  medium  level  was  selected  as  6U 
seconds,  half  the  maximum  allowable  time.  A  low  level  of  It) 
seconds  was  arbitrarily  selected  as  a  reasonable  lower  limit 
on  the  processing  speed  of  the  CIS-ISS.  These  levels  were 
also  compared  against  some  operational  test  and  evaluation 
data  on  the  CRC  performed  in  1971  which  showed  an 
identification  time  average  of  65  seconds  [CI’C  OT&E, 

1971:85].  The  actual  values  used  were  input  as  the  "first 
service  time"  within  the  S1U1.DAT  input  file  for  the  modified 
TADZ  model.  The  code  reads  these  values  as  the  means  of 
exponential  distributions.  Appendix  1)  lists  the  goodness  of 
fit  tests  and  results  of  the  data  reduction  and  distribution 
analysis  for  several  of  the  model  inputs  including  the  high 
value  of  the  identification  time. 


■leas tires  o  f  tor  i  t 

inere  were  two  measures  of  merit  or  performance  selected 
to  evaluate  the  differences  between  the  various  combinations 
of  the  input  factors.  The  first  measure  of  merit  was  the 
number  of  hostiles  that  get  through  the  air  defense  zone 
without  being  engaged  and  "killed"  by  either  the  SAM's  or 
fig  liters.  The  second  measure  was  the  number  of  fratricides 
that  occurred  during  each  run  of  the  simulation.  These  two 
measures  were  deemed  to  capture  the  essence  of  what  an 
identification  decision  aid  should  bring  to  the  tactical  air 
control  system  --  the  ability  to  destroy  more  enemy  aircraft 
while  destroying  fewer  of  our  own. 

Ana  lysis  o f  Variance 

With  three  factors  at  three  levels  each,  the  resultant 
experiment  was  a  3^  design  requiring  27  simulation  runs  for 
each  replication  desired.  See  Figure  1U  for  a  three 
dimensional  representation  of  the  3x3  design.  Since  the 
factor  levels  were  not  randomly  picked,  this  analysis  is  a 
fixed  effects  model  and  consequently  the  results  cannot  be 
extrapolated  outside  the  factor  levels  of  the  design 
[Montgomery,  1984:44  ]. 

Hue  to  the  size  of  the  experimental  design,  it  was 
decided  to  limit  this  initial  experiment  to  only  one 
replication.  This  decision  required  an  assumption  that  the 
three  way  interaction  was  negligible  in  its  contribution  to 


explaining  tne  variance.  An  expanded  "Tukey's  additivity" 
test  was  performed  on  both  of  the  measures  of  merit  to  verify 
the  assumption  of  negligible  three  level  interactions  which 
is  required  to  justify  the  use  of  one  replication  in  the 
analysis  of  variance  [Kirk,  1982:250-253].  The  additive 
model  (no  three  level  interaction)  assumption  was  verified  at 
alpha  levels  ranging  from  5  to  '2  5  percent  as  suggested  by 
Kirk. 

The  ANOVA  for  the  number  of  successful  penetrators  is 
contained  in  Table  VIII.  Note  that  for  the  first  measure 
(number  of  hostiles  through),  identification  time  and 
accuracy  were  both  significant  at  the  5  and  10  percent  levels 
indicating  a  definite  contribution  to  the  variance.  The 
capability  factor  was  found  to  be  insignificant  at  both  10 
and  5  percent  levels.  A  brief  discussion  of  the  effects  of 
each  of  the  factors  is  presented  below. 

Accuracy.  As  the  graphs  in  Appendix  D  indicate,  as  the 
accuracy  of  the  system  increases,  the  number  of  penetrators 
that  get  through  the  air  defense  zone  decreases.  This  effect 
of  accuracy  on  the  number  of  hostiles  killed  is  intuitively 
appealing.  The  more  accurate  the  identification,  the  greater 
the  number  of  hostiles  that  should  be  killed.  Th i s  is 
because  fewer  hostile  aircraft  get  through  the  air  defense 
zone  because  they  are  miss-identified  as  friendly. 

1 1)  Time.  However,  the  effect  of  identification  time  on 
the  first  measure  of  merit  was  different  than  expected.  The 
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Variate 

Fac  tor 

Sum  o  f 
Squares 

Degrees  of 
Freedom 

iiean 

Square 

F 

Statistic 

i  :  I  lit  i  me 

2968.2 

2 

1484.1 

22 . 38ab 

c :  Capability 

12.6 

2 

6 . 3 

0.10 

a :  Accuracy 

5936. 8 

2 

2968 . 4 

44 .  77ab 

i  c 

371.1 

1 

92 . 7 

1  .  10 

i  a 

1362.2 

4 

3  4  0.2 

3.14ab 

ca 

301.1 

4 

75.2 

1.14 

i ca :  Error 

530.4 

8 

6  6.3 

To  t  a  1 

52801.3 

1 

a  =  significant  at  5%  b  =  significant  at  10% 


number  of  hostiles  through  was  less  for  the  1 onger  ID  times! 
Upon  examining  the  model  outputs  for  network  message  flow,  it 
appeared  that  ns  the  system  processes  more  and  more  detection 
messages,  the  vl&  1  section  begins  to  backlog.  However,  the 
system  does  not  backlog  forever.  If  the  TADZ  model  determines 
that  normal  message  processing  (through  the  1& I  section)  will 
prevent  penetrator  prosecution,  the  model  will  allow  the 
individual  Cbs  to  begin  prosecution  if  that  is  the  only  means 
to  prevent  the  penetrator  from  successfully  penetrating  the 
air  defense  zone.  As  the  It)  time  is  extended,  the  backlog 
occurs  earlier  and  the  system  defaults  sooner.  As  the  model 
defaults  at  an  earlier  time,  the  C°s  begin  to  prosecute  every 


penetrator  within  its  operating  area,  thus  accounting  i'or  the 
fewer  successful  penetrators.  The  default  TADZ  model 
prosecution  mode  also  does  not  resolve  dual  prosecution  for 
those  C^s  with  overlapping  coverage.  The  model  reflects  the 
actual  operational  processes  in  this  regard.  The  weapons 
assignment  section  will  not  allow  penetrators  to  exit  the 
system  without  prosecution  just  because  of  a  backlog  in  the 
movements  and  identification  section. 

There  is  also  some  indication  that  the  use  of  speed  of 
identification  as  a  factor  may  have  been  a  less  than  optimum 
choice  as  a  factor  variable.  Using  time  as  a  criteria  for  lb 
does  not  preserve  the  independence  between  the  11)  time  factor 
and  the  tactical  decision  time  for  employment  of  assets. 
Chapter  VI  contains  a  more  detailed  discussion  of  this  point. 

Capa b i 1 i t y .  The  level  of  the  capability  or  percent  of 
unknowns  was  found  to  have  no  significant  effect  on  the 
model  outputs.  The  increase  in  the  number  of  unknowns  will 
cause  an  increase  in  the  number  of  engagements  required  for 
fighter  interceptors  and  fev/er  engagements  for  the  SA  I  sites. 
A  closer  examination  of  the  output  data  revealed  that  the 
number  of  SA‘1  kills  remained  constant  over  all  factor  levels 
in  the  model.  The  number  of  wasted  assets  would  be  the 
sorties  that  engaged  unknown  friendly  aircraft.  Since  only 
It)  percent  of  the  penetrators  are  friendly  and  the  number  of 
unknowns  ranged  from  7  (  3  2  0  x  .  0  2  )  to  j2  (3  2  0  x  .10  ),  the 
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killed  are  the  aircraft  that  are  identified  incorrectly  as 
hostiles.  Since  this  result  depends  solely  on  the 
identification  accuracy  (in  this  model),  the  results  are  as 
expected. 

Interaction  graphs  for  both  measures  of  merit  were 
constructed  for  all  possible  combinations  of  the  three 
factors  at  all  three  levels.  The  significant  graphs  are 
displayed  in  Figures  11  and  12.  Figure  11  shows  three  graphs 
with  capability  being  held  constant  at  one  level  for  each  of 
the  grapns.  Note  that  as  accuracy  and  time  increase  the 
graphs  decline  to  the  right  showing  the  previously  mentioned 
decline  in  the  number  of  hostile  penetrators  making  it 
through  the  air  defense  zone.  Figure  12,  which  has  time  held 
constant  for  each  graph,  shows  that  as  capability  increase 
for  each  level  of  accuracy  there  is  little  overall  effect. 
These  graphs  further  describe  the  trends  and  results  just 
discussed.  The  remainder  of  the  interaction  graphs  are  found 
in  Appendix  l). 

Sensitivity  Ana  lysis  on  Enemy  Tact i c s 

The  initial  analysis  just  described  provided  a  basis  for 
choosing  the  combination  of  factors  which  were  used  for 
modeling  the  CIS-ISS  in  the  baseline  scenario.  The  following 
factor  levels  were  chosen  to  model  the  CIS-ISS.  Accuracy  was 
set  at  the  99  percent  level  to  maintain  a  zero  fratricide 
level.  Capability  was  set  at  98  percent  und  a  10  second  10 
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t  i  10  was  chosen  as  tne  fastest  processing  time.  >.ith  the 
CIS- 16  3  factor  levels  at  these  settings,  the  model  was  tested 
for  sensitivity  to  variations  on  enemy  tactics  as  described 
in  the  following  paragraphs. 

iteduced  dumber  o  f  Pene  t  ra  t  o  r  s .  The  original  scenario 
used  a  total  of  320  penetrators.  This  number  was  an  upper 
limit  due  to  memory  limitation  of  the  TADZ  model.  This 
limitation  will  be  further  explained  in  Chapter  VI.  A 
reduction  of  penetrators  of  20  percent  (256  vice  320)  was 
input  and  the  results  were  compared  to  the  original  scenario. 
A  one  way  ANOVA,  using  a  sample  size  of  10,  indicated  a 
significant  difference  in  means  between  the  two  levels  of 
penetrators  using  the  F  statistic  at  the  10  percent  level. 
This  difference  was  found  to  be  statistically  insignificant 
using  the  Duncan  multiple  range  test  at  the  5  and  10  percent 
levels.  The  natural  conclusion  was  that  the  number  of 
penetrators  did  not  change  the  results  of  the  simulation. 

Upon  examining  the  times  of  the  penetrator  kills,  it  was 
found  that  the  air  defense  system  is  most  effective  during 
the  start  and  end  of  the  wave  attack.  In  general,  the 
successful  penetrators  are  the  middle  of  the  wave  while  the 
system  is  occupied  with  the  start  of  the  wave.  See  Table 
X  for  the  actual  test  data  results  on  variations  of  enemy 


tactics. 


i  i  _£  h  t  Size.  The  original  scenario  used  i  constant 
value  of  4  aircraft  per  flight  of  penetrators.  Spreading  out 
the  total  number  of  hostile  aircraft  by  reducing  the  flight 
size  should  make  the  air  defense  tasks  more  difficult.  This 
hypothesis  was  tested  by  reducing  the  flight  size  to  a 
constant  level  of  2  aircraft.  With  the  number  of 
replications  set  to  10,  a  one  way  A  NOVA  was  performed  to 
compare  to  the  original  scenario.  The  F  test  indicated  a 
significant  difference  in  cell  means  and  the  Duncan  test 
confirmed  that  the  smaller  flight  size  increased  the  number 
of  hostiles  that  "got  through"  the  system  (as  hypothesized). 
Table  X  shows  the  pertinent  statistics. 

Spac i ng  o f  the  Penetrators.  The  number  of  seconds 
between  the  penetrator  flights  was  also  thought  to  effect  the 
performance  of  the  air  defense  system.  The  original  scenario 


Table  X.  Sensitivity  on  Enemy  Tactics. 


Scenario 


Au  t  on,i  t  ed 

Pene  t  ra  tors 
2  5  6 

Spacing 
30  seconds 

Flight  Size 
2  A/C 

Path  Routing 


i.  Through 

F-s  t  a  t 

Duncan 

( Mean ) 

S i gn i f  ? 

S  i  gn  i 

38.0 

— 

— 

3  0.0 

Yes 

No 

5  6.6 

Yes 

Yes 

4  0.0 

Yes 

Yes 

50.8 

Yes 

Yes 

used  a  value  of  15  second  spacin'  bet  ./eon  individual 
flights.  Th i s  was  considered  an  upper  limit  on  compress i n  ; 
the  arrival  rate  based  on  information  from  Soviet  '•! i  1  i  t a r y 
Power,  and  Coyne's  article  in  Air  Force  Magazine  (Soviet 
Military  Power,  1985:103;  Coyne,  1984:74].  Ten  replications 
were  run  at  a  spacing  of  30  seconds  and  the  results  were 
compared  to  the  original  scenario  using  the  one  way  ANOVA. 
Both  the  F  test  and  the  Duncan  test  indicated  a  significant 
increase  in  the  number  of  hostiles  that  penetrated  the  air 
defense  zone  when  the  spacing  was  increased.  This  result  was 
to  be  expected  as  the  fighter  assets  were  made  to  work 
"harder"  when  the  penetrators  were  more  spread  out.  Thus  the 
penetrators  did  not  present  such  lucrative  target  clusters. 
The  actual  statistical  results  are  found  in  Table  X. 

Pene  t  ra  t  or  Pa  t  h  s .  The  original  scenario  hud  3  parallel 
penetrator  paths  running  through  the  100  km  by  100  km  air 
defense  zone.  V  more  realistic  tactic  for  the  enemy  would  be 
to  vary  the  routing  of  the  paths  to  increase  the  difficulty 
of  the  tracking  and  intercepts  ov  the  air  defense  assets. 

The  paths  were  changed  to  reflect  such  a  tactic  and  the  A  MOV  A 
was  again  used  to  compare  the  results  with  the  original 
routing.  See  Figures  13  and  14  for  a  comparison  of  the  two 
scenario  penetration  paths.  Both  the  F  and  Duncan  tests 
indicated  a  significant  increase  in  the  number  of  penetrators 
not  killed  when  the  paths  were  made  more  complex.  Table  X 
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lists  the  statistical  results  for  this  coir, oar  i  son  also.  'll 
of  the  auove  analyses  essentially  tested  the  model's 
sensitivity  to  the  changes  in  the  enemy's  penetration 
tactics. 

Sensitivity  Analysis  on  Friendly  Tact i cs 

Several  "friendly"  tactics  were  also  evaluated  using  the 
modified  TADZ  model.  These  tests  are  in  addition  to  those 
already  considered  in  the  area  of  increased  identification 
efficiency.  These  excursions  include  the  command 
configuration  of  the  surface  to  air  missiles  and  a  variation 
on  the  location  of  the  CAP  points  for  the  air  defense 
fighters. 

SA  1  Command  Con  f i gura  t ion.  The  original  scenario  had 
the  SA.l's  set  up  in  a  "square"  configuration  which  permitted 
two  platoons  at  each  of  the  four  SAM  sites  or  batteries. 

This  configuration  allows  for  only  t  wo  simultaneous 
intercepts  at  each  site  [Combined  Arms  Fundamentals, 

1 y 8 J : 5. 1  2 , 5.2 7  ] .  The  "triad"  con f i gura t i on  puts  one  more 
platoon  at  each  battery  and  therefore  allows  for  three 
simultaneous  intercepts  per  site.  While  the  actual  number  of 
missiles  or  platoons  were  not  changed,  the  number  of 
simultaneous  intercepts  was  increased  to  three.  Ten 
replications  were  run  using  the  new  configuration  and  the 
results  were  compared  to  the  original  scenario.  The  ANOV  \ 
indicated  a  difference  in  the  means  and  the  Duncan  tost 
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eon  f  i  r  .Tied  tn.tt  tno  triad  eon  f  i  ;n  r.i  t  i  on  i  n  cro.i  s  e  J  t  he  number 
o  t'  hostiles  that  successfully  penetrated  the  air  defense 
zone.  See  Table  XI.  v\  h  i  1  e  examining  the  model  and  its 
outputs  to  understand  the  reason  for  the  increase  in  the 
number  of  successful  penetrators,  a  significant  insight  to 
the  functioning  and  implications  of  the  node!  was  brought  to 
light. 


Table  XI.  Sensitivity  on  Friendly  Tactics. 
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would  only  occur  if  such  actions  //ere  the  only  .Method  to 
prevent  the  penetrator  from  exiting  the  air  defense  zone 
without  prosecution.  Thus,  as  ID  times  were  extended  and 
larger  backlogs  occurred,  more  and  more  penetrators  were 
attacked  outright  without  the  ID  processing  delay  -- 
permitting  fewer  penetrators  to  escape.  Thus  the  single 
identification  processor  providing  a  10  second  average 
processing  time  nay  be  inadequate.  Also,  since  the 
uacklogged  system  can  not  execute  as  a  total  air  defense 
system,  the  system  begins  to  prosecute  each  penetrator  as  it 
enters  each  C°s  area  of  responsibility.  In  addition,  since 
the  system  operates  in  the  default  node,  there  is  no  dual 
prosecution  resolution  for  overlapping  areas  of 
responsibility  at  the  missile  C^s.  Thus  the  SAM  sites  are 
only  effective  until  the  M&I  section  backlogs  and  then  the 
additional  server  appears  to  cause  increased  conflict  among 
the  prosecutors  allowing  more  penetrators  to  successfully 
pass  through  the  air  defense  zone. 

CAP  Location.  The  base-line  scenario  had  the  CAD's 
located  approximately  in  the  center  of  their  assigned  areas 
or  zones  (see  Figure  15).  .loving  these  locations  to  a  more 
forward  location  was  hypothesized  to  improve  the  fighters' 
ability  to  engage  and  kill  the  incoming  penetrators.  The  CA1 
locations  were  moved  forward  26  kilometers  (penetrator  speed 
times  the  additional  ID  processing  time).  The  CM'  positions 


were  i  1  so  test’d  at  13  a  i  I '>  inters  toe  v.ird  (half  the 
uista  nee).  Tae  resulting  avenge  nun'jcr  of  pene t ra tors ,  for 
ten  runs,  through  was  not  statistically  different  from  the 
manual  or  automated  system.  Tnese  outputs  are  also  included 
in  Table  XI. 

The  llesea  ren  Quest  ion 

Recall  that  the  main  purpose  for  this  effort  was  to 
determine  a  range  of  optimal  response  rates  to  model  the 
automated  identification  feature,  specifically  C1S-ISS.  In 
addition,  a  comparison  between  the  automated  and  manual 
systems  was  also  proposed.  The  analysis  thus  far  has 
evaluated  an  automated  system  based  on  the  measures  of 
accuracy,  capability,  and  identification  tine.  The  question 
remains:  does  this  projected  automated  system  (CIS-1SS)  do  a 

better  job  than  the  current  (manual)  system?  Table  XII  lists 
the  factor  levels  to  be  used  in  this  comparison. 

Table  XII.  Comparison  Factors. 


C I S- I SS  ,anual 


Factor 

Ca pab i 1 i t  y 

2  i 

0  ‘6 

Ac  c  u racy 

9  9  '6 

9  U  & 

ID  Time 

1  U  sec 

112  sec 

100 


Using  Wilcox's  method,  mentioned  earlier  in  Cnaptcr  2, 
trie  two  systems  were  compared  [Wilcox,  1985:45-54].  Using 
an  initial  10  runs  for  the  manual  system,  a  mean  of  35.6 
hostile  penetrators  made  it  through  the  air  defense  zone. 

This  is  12.36%  of  the  total  number  of  hostiles  (35.6  / 

(320*. 90))  available.  It  was  hypothesized  that  if  the  CIS-I3S 
could  reduce  the  percentage  to  6%  (half  the  manual)  the 
system  would  be  selected  over  the  manual  system.  If  the 
automated  system  was  not  as  good  as  the  manual  system  we 
would  prefer  the  manual,  and  we  would  be  indifferent  for  any 
performance  between  these  two  values.  Specifically,  select 
manual  if  the  number  through  is  greater  than  36  (35.6)  and 
select  tne  automated  if  the  number  is  less  than  17  (17.28). 

If  the  number  is  between  17  and  36  the  decision  maker  would 
be  indifferent  to  the  new  system  and  would  remain  with  the 
standard.  Thus  <1*  =  9.5,  and  the  midpoint  of  the 
indifference  zone  is  26.5.  If  the  final  automated  mean  minus 
the  manual  mean  is  less  than  d  *  the  test  says  to  select  the 
manual  system,  and  if  the  difference  is  greater  than  d* 
select  the  automated  system. 

Using  the  initial  number  of  runs  as  10,  the  mean  of  the 
automated  system  is  38  and  the  manual  is  35.6  with  sample 
variances  of  4  and  7.305.  The  ’  h '  value  for  a  probability  of 
955  correct  decision  is  2.61  [Wilcox,  l'J85;47J.  The 
calculated  number  of  samples  needed  is  10  and  10.21  for 
automated  and  manual  respectively.  Tne  formulas  used  to 


calculate  the  number  of  samples  are  listed  below.  .  <a  is  the 
number  of  runs  required  for  the  automated  systems.  ‘Jn  is  the 
number  of  runs  required  for  the  manual  system. 

Na  =  max  [10,  ( 2 . 6 1 / 9 . 5 ) 2  * ( 4 ) 2  ] 

Nfl  =  max  [10,  2.0] 

Nm  =  max  [10,  <2.61/9.5)2*(7.805)2] 

Mm  =  max  (10,  10.21] 

Therefore  an  additional  sample  was  taken  for  the  manual 
system  and  the  new  mean  was  35.8.  Since  the  difference  was 
less  than  9.5  (38  -  35.8  =  2.2),  this  test  indicates  that  we 
should  not  select  the  automated  system  (as  modeled). 

Summary 

This  chapter  has  described  the  analysis  of  the  results 
from  the  experimental  design.  While  in  some  instances,  the 
results  were  not  as  expected,  they  were  understandable  upon 
closer  examination.  The  final  analysis  showed  that  a  single 
ID  processor  as  modeled  is  not  adequate  for  identification 
purposes.  Due  to  the  backlog  that  occurs  in  both  the 
automated  and  manual  systems  there  were  no  significant 
operational  differences  between  the  two  systems  us  modeled. 

In  addition,  the  model  sensitive  to  the  enemy  tactics 
employed  while  indifferent  to  the  friendly  tactics  employed. 


VI.  Conclusions  and  Recommendations 

Summary 

In  order  to  provide  a  framework  for  the  conclusions  and 
recommendations  contained  in  this  final  chapter,  a  summary  of 
the  purpose,  assumptions,  scenario  and  the  methodology  will 
he  presented. 

Purpose.  The  goal  of  this  thesis  was  to  examine  the 
range  of  working  parameters  required  in  the  combat 
identification  system  -  indirect  subsystem  (CIS- I SS)  to 
prevent  backlogs  under  simulated  combat  conditions  in  the 
control  and  reporting  center  (CRC).  The  model  was  analyzed 
to  investigate  the  interactions  between  the  different 
parameters  used  in  the  CIS-ISS. 

Assumpt ions.  Three  major  assumptions  were  used  in 
modeling  the  CIS-ISS: 

1-  the  identification  sensor  and  supporting  radars  were 
collocated  with  approximately  the  same  coverage. 

2.  the  identification  function  would  remain  at  the  CRC 
movement  and  identification  section  (a  man  in  the  loop) 
with  centralized  inputs  from  all  other  radars  and 
identification  sensors. 

3.  the  most  stressful  test  of  the  CIS-ISS  would  be  the 
employment  of  the  TACS  using  u  central  Kuropean  type 
scenario. 

Scenar i o.  The  simulated  test  environment  was  a  CRC 
using  three  CAP  points  using  three  squadrons  of  F-15s.  The 


(  '  modeled  corttroled  4  dawk  batteries  .vita  a  total  of  72  missile 

ready  to  fire.  The  threat  consisted  of  320  penetrators  flying 
in  flights  of  4  with  lo  second  spacing.  The  penetrators 
arrived  along  8  separate  paths.  Ten  percent  of  the  penetrators 
were  identified  friendly  and  the  remaining  ones  were  hostile. 

See  Figure  ltj  for  a  representation  of  the  modeled  air  defense 
zone  . 

1e  t  hodo 1 ogy .  Simulation  was  selected  to  test  the 
parameters  for  the  CIS-ISS.  The  simulation  model  used  was 
the  transient  air  defense  zone  (TADZ)  model  provided  by 
Foreign  Technology  Division  (FTD).  It  was  modified  to  use 
identification  codes,  conduct  identification  intercepts  and 
to  selectively  not  prosecute  penetrators  based  on  the 
identification  codes.  Three  parameters  were  used  to  model 
tne  CIS-ISS:  capability  (the  percent  of  unknowns),  accuracy 
(percent  correct),  and  time  to  identify  (how  long  the 
identification  process  takes).  The  three  parameters  were 
each  tested  at  three  factor  levels  and  a  3  anulysis  of 
variance  test  was  performed.  Two  measures  of  merit  were 
used,  total  number  of  successful  penetrators  through  the  air 
defense  zone  and  number  of  friendlies  destroyed  (fratricide). 

The  analysis  of  variance  (ANCVA)  showed  that  the 
significant  factors  for  the  first  measure  of  merit,  the 
number  of  successful  penetrators,  were  accuracy  and 
i den t i f i ca t i on  time.  Capability  was  not  significant  3t  the 


levels  tested  due  to  the  small  number  of  friendly  unknowns 


modeled  in  the  scenario.  Accuracy  was  a  significant  factor 
and  as  accuracy  increased,  the  total  number  of  successful 
penetrators  and  fratricides  decreased.  Identification  time 
(ID)  time  was  also  significant.  However,  the  effect  was  the 
opposite  of  what  was  anticipated.  The  number  of  successful 
penetrators  decreased  as  ID  time  increased.  ID  time  was  not 
significant  for  fratricides. 

Sensitivity  tests  conducted  on  variations  in  the 
penetration  tactics  were  all  significant  indicating  that  the 
model  is  sensitive  to  changes  in  spacing  between  flights, 
size  of  the  flights,  and  the  paths  flown.  For  this  reason 
the  conclusions  presented  are  dependent  on  the  scenario 
tested  and  should  not  be  extrapolated  beyond  the  threat 
tested  in  the  model.  Sensitivity  tests  on  friendly  tactics 
shoved  that  the  model  was  insensitive  to  changes  in  the 
comoat  air  patrol  (CAP)  locations  (forward  positions)  and 
sensitive  to  tne  number  of  simultaneous  surface  to  air 
missile  (SA\1)  intercepts.  The  greater  the  number  of 
simultaneous  intercepts  allowed,  the  worse  the  system  as  a 
whole  performed. 

Cone  1  us i ons 

An  analysis  of  the  CIS  -  I  SS/CIIC  as  modeled  led  to  the 
following  two  conclusions.  First,  the  single  centralized 
CIS-ISS  processor  desired  by  the  operational  users  may  not  be 
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as  an 


teas  i  ale.  Secondly,  the  use  of  "time  to 
operational  parameter  may  not  oe  an  adequate  measure.  i'nese 
two  points  will  be  discussed  in  tne  following  paragraphs. 

C I S -  1 S S  Over  1 oad.  Tne  examination  of  model  output 
showed  that  tne  reason  for  the  opposite  effect  of  ID  lime  was 
because  the  identification  processor  was  creatin'  a  backlog 
in  message  processing  within  the  CKC.  When  the  modeled  CIS- 
ISS  begins  to  backlog,  rattier  than  let  penetrators  through 
without  processing,  the  CliC  defaults  to  an  'autonomous  mode' 
where  each  Hawk  site  and  CAP  point  attempts  to  prosecute 
every  penetrator  within  its  assigned  area  of  responsibility 
without  awaiting  an  identification  code.  Tne  longer  the  ID 
times,  the  sooner  the  system  went  into  the  default  mode.  The 
quicker  the  system  enters  the  'autonomous  mode'  the  more 
penetrators  are  destroyed.  In  the  autonomous  mode,  dual 
engagement  of  the  sane  penetrator  by  two  different  SAMs  or 
fijhters  nay  occur.  Thus  an  increase  in  number  of  prosecutor 
servers  causes  poorer  performance  (more  dual  conflicts). 

Even  at  the  fastest  processing  time  modeled  for  the  CIS- 
ISS  (1U  seconds  per  ID)  the  system  backlogs.  The  OIS-ISS,  as 
modeled  with  a  single  central  processor,  can  not  handle  the 
threat  load  presented.  An  simple  queueing  unalysis  of  tne  arrival 
and  service  times  also  indicated  the  CIS-ISS  would  oacklog. 

A  simplified  queuing  system  of  the  thesis  scenario  can  be 
visualized  as  shown  in  Figure  17.  Several  assumptions  were 
made  reduce  the  system  to  this  simple  queuing  system.  First, 


the  eight  penetrator  paths  were  assumed  to  present  a  single 
queue  or  customer  population.  \ssuning  that  the  CIS- 1  S3 
would  identify  the  penetrator  flights  as  a  whole  rather  than 
as  individual  aircraft,  the  number  of  tracks  or  customers  is 
reduced  to  80  arrivals  over  a  time  span  of  approximately  2.5 
minutes.  This  assumption  yields  an  arrival  rate, X  ,  of  one 
penetrator  every  2  seconds.  Caking  the  assumption  that  the 
CIS-13S  is  a  single  server  with  a  service  t  \  me ,  JjL  ,  of  one 
every  lu  seconds,  the  utilization  factor,  ^0  ,  for  this 
queuing  system  would  equal  5  (10  divided  by  2).  An  intuitive 
conclusion  at  this  point  would  indicate  that  this  system 
cannot  possibly  work  when  the  customers  are  arriving  5  times 
faster  than  they  can  be  served.  In  analytical  terms,  such  a 
queuing  system  cannot  reach  "steady  state"  unless  the 
utilization  factor  is  less  than  one  [Millicr  and  Lieberman. 
1080:417]. 

In  order  to  follow  through  with  some  simple  analytical 
calculations,  several  further  adjustments  would  have  to  be 
made.  Two  solutions  are  immediately  evident.  The  first 
would  be  to  to  insist  on  a  CIS-ISS  service  time  of  much  less 
t  h  a  n  10  seconds,  a  minimum  value  of  1.75  seconds  would  be 
required  for  the  simplified  system  mentioned  earlier.  A  two 
second  response  time  i  den t i  f i ea t i on  response  rate  does  not 
seem  feasible,  especially  with  the  requirement  for  a  man  "in 
the  loop."  To  verify  that  a  one  second  response  rate  would 


ease  tie  .1  odp  1  va  s  run  with  a  one  second  < '  I  S  —  I  :i  S  response 
tine.  At  the  faster  response  rate  the  IA  l  section  did  not 
backlog.  However,  a  backlog  did  occur  in  the  weapons 
assignment  section  for  the  selection  of  air  defense  assets 
( SA'Is ) .  It  should  be  noted  that  the  time  used  to  model  tne 
decision  time  for  the  SAMs  (56  seconds)  was  based  on  the 
Kg  1  i n  test  data  (a  limited  scenario)  and  may  not  be  a  valid 
response  time  for  a  higher  threat  environment. 

\  second  approach  to  enaDle  an  increased  C1S-ISS 
resoonse  rate  would  be  to  increase  the  number  of  servers  to 
effectively  decrease  the  average  service  time  of  the  system. 

In  the  scenario  described  in  this  study,  installing  the  CIS- 
I  S3  ut  each  radar  site  would  approach  tne  required  number  of 
servers.  This  distributed  CIS-ISS  proposal  would  require  the 
user  to  develop  a  change  in  the  operational  concept  for  a  single 
centralized  air  space  manager  responsible  for  identification. 

I’he  success  of  both  of  the  previoulsy  mentioned  solutions, 
one  second  response  time  and  multiple  servers,  are  predicated 
on  reducing  the  utilization  factor  to  less  than  one. 

The  arrival  rate  in  the  used  in  the  model  has  been 
dictated  by  what  the  authors  believe  to  be  a  reasonable 
"worst  case"  scenario  derived  from  the  unclassified 
literature.  Perhaps  a  si  mole  study  using  the  actual 
intelligence  estimates  of  the  threat  would  resolve  the  issue 
of  whether  or  not  the  CIS-ISS  <.  a  n  keep  up  with  the  expected 
load  in  an  actual  conflict.  This  simple  queuing  analysis. 


even  though  at  a  cursory  level.  does  provide  insignt  i  n  t  o 

this  backlog  proulem.  The  utilization  rate  of  tnc  "system" 

as  a  whole  must  be  reduced  to  increase  the  efficiency  of  the 

system.  The  central  single  processor  for  the  CIS-ISS 

cannot  "do  the  job"  in  the  environment  in  which  it  will  be 

expected  to  perform  -  as  it  was  modeled  in  this  thesis. 

IP  f i no  as  a  Factor.  The  use  of  identification 

processing  speed  as  a  CIS-ISS  parameter  .nay  not  do  valid.  It 

may  not  preserve  the  independence  between  tactical  decisions 

to  employ  assets  and  the  time  to  identify  the  penetrators. 

l’nis  same  point  was  made  by  ,'lajor  Hess  (Herman  Air  Force 

[OAF],  Rrockzetel),  a  master  con t ro 1  1  er-- t he  equivalent  of  a 

IvAO/Senior  Pi  rector  in  the  TAC3.  lajor  Hess  suggested  that 

in  a  combat  situation,  the  amount  of  time  (per  se) 
needed  to  accomplish  an  IP  was  a  less  valid  measure 

than  the  ability  to  have  an  unknown  aircraft  identified 
before  it  flew  out  of  the  effective  engagement  zone  of  a 
weapons  system  (e.g.,  sur  faec-to-nrc  missiles).  The 
ingredients  contained  in  the  measure  allude  to  the 
interrelationship  between  parameters  inside/outsidc  the 
system  boundaries  that  must  be  considered  when  dealing 
with  measures  of  syrtem  performance.  Straight  measures 
of  timeliness/ accuracy  appear  meaningless  unless  woven 
into  the  context  of  integrated  air  defense  operations, 
[l’reidis  and  Spaeth,  1J85:J]" 


Rccommenda t ions 

Distributed  CIS-  1 S S .  Due  to  the  saturation  of  the  ('IS¬ 
IS  S  as  modeled,  it  is  recommended  that  a  further  study  do 
conducted  to  model  a  effect  of  a  distributed  identification 
function  at  each  CIS-ISS  sensor  verses  the  central  processor 
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desired  by  the  Djjeration.il  users.  The  study  Should  seek  to 
analyze  tne  benefits  and  trade-offs  to  distributing  the 
identification  process  verses  the  current  stated  operational 
requirements  for  a  centralized  configuration. 

Expanded  Te  s  t  Mata.  The  distributions  and  tines  used  in 
this  study  //ere  based  on  limited  sample  data  from  a  simple 
scenario  employed  in  the  May  1985  Eg  1  i  n  test.  \dditional 
analysis  on  the  more  expanded  tests  conducted  in  Europe 
should  be  used  to  test  and  validate  the  assumptions  on  the 
distributions  used  in  this  model. 

Selective  Prosecut ion.  A  study  should  be  conducted 
us  i  n^j  a  selective  prosecution  based  on  identification  of 
aircraft  type  and  mission.  For  example,  what  benefits  can  be 
derived  from  prosecuting  ground  attack  ajrcraft  while 
not  prosecuting  hostile  penetrating  air-to-air  fighters? 

Ke  v  i  ew  the  TADZ/  SEA  1  Mode  1 .  During  the  process  of 
modifying  TADZ  to  implement  the  changes  required,  several 
problems  were  encountered  in  trying  to  compile  and  link  the 
provided  source  code.  In  particular  the  original  simulation 
language  for  alternative  modeling  (SLAM)  source  code  provided 
could  not  be  recompiled  and  linked  without  errors.  While  the 


compiled  SLA  1  object  file  did  execute  sa t i s f a c t o r 1 y  with  the 
modified  TADZ  object  file,  occasional  unexplainable  runtime 
errors  did  occur.  Since  the  l'AUZ  code  did  require  complete 


recompilation  to  run  on  the  VA.\/V.!S  1  1  -  7  85  (the  code  was 
developed  on  a  V  A  \  /  VM  S  1  1  -  780  ),  it  is  not  known  whether  the 
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tne  TAD7,  model  and  its  documentation  in  future 
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(Page  A-4>  The  identification  orcbatilit 
contained  at  the  end  of  this  tile  are  cumulative 
probabi 1 i tss.  The  actual  prcbabi 1 i ti es  for  each  cede  (r?c 
Figure  ?>  can  be  found  by  taking  the  differences  between  t 
successive  orobabi 1 i ti es. 

ibQBIPIPiiPOB  and  LCNGF- IRgJFQR  (Pace  A-5  and  A- 15) 
These  code  changes  are  explained  in  Chapter  IV  and  are  not 
logical  and  straight  forward. 

CCriAICH^FQR  (Page  A-30)  It  should  be  -amemDersd  tha 
change  in  the  number  of  COFI  will  require  >*ecomo  i  1  at  i  on  of 
the  code  in  this  file.  In  addition  the  organization  of  tb 
data  files  assumes  that  all  fighter  C's  are  listeo  first  l 
the  data  execution  file  (CASE.DAT). 

USERFiFCR  (Page  A-36)  This  * i 1 e  actually  contains  t 
separate  subroutines.  USERF  and  SERVICE  TIME.  The  second 


file,  SERVICE  TIME 


routine  r  e  q  u i r i n  g  t  n  e  c  h a n  q  e , 


only  change  required  is  to  charge  the  :rIR3-_ME33ASE__IME  - 
a  UNIrCPM  d :  st  r  i  but  i  or.  to  an  EXrCNENTI.AL  ere.  s  ordinal 

code  has  been  commented  cut  and  is  still  in  the  -*110. 

The  actual  files  used  are  listed  ir  th  s  tree**  ;ust 

p  Z '  5 j^a-j  1  n  p  h  r  cd :Ti  3. 1  r.  Z  S ^  Z  I  r  , p  p  0 H  -  •_  u  £  p  p  p  'f. r' 

on  a  sec er ate  pace. 
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THIS  COMON  SL SEX  HOST  PDLLDK  AFTER  ’PAWWETES.DIM* 

AS  THAT  PILE  STAINS  THE  DEFINITION  OF  THE  VALUE  FOR 

MAX  _NUH_PENETRAT2.PS 

COHNCN  /PIDTAB/PEN.IDENUKAX 

_NUN_°ENErPATOFS! 

REAL  ?EN_IDENT 

SCN£TPATC?  IIET!rY  STATUS  T 

ABLE 

"'■'r-r  *■> 

ACTUAL 

i  UNKNOWN 

HOSTILE 

2  UNKNOWN 

FRIENDLY 

3  HOSTILE 

HOSTILE 

4  HOSTILE 

FRIENDLY 

5  FRIENDLY 

HOSTILE 

6  FRIENDLY 

CR!ENDLY 

7  DELIBERATE  NONE  PROSECUTION 

3  CRIENDLY  ORIGINAL  UNKNOWN 

I 

s 

$ 

i 


✓ 


I 

'  i 


PEN INT 

’PENINT’  INITIALIZES  THE  FENETRATOR  TABLES  FOR  USE  IN  THE  DYNAMIC 
SESNENT  Dc  THE  SINULATIQN. 


ALPHATECH. INC. 

ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 

SP80ri|TtVj£  sc>|M(T 

IMPLICIT  NONE 

c  ttttttmttmmmm  inclose  common  blocks  tutittiimimuitiit 

n 

INCLUDE  ' DCO : PAR ARETER . 3 !»• 

INCLUDE  1 DCQ:5Y=LIMITS.PRM’ 

INCLUDE  ’DCO: PENTIM. PPM* 

INCLUDE  ’DCOifENST.PRN’ 

INCLUDE  ’DCO:  NR, HEAD.  PRN’ 

INCLUDE  ’ DCO : PATHPEM. 3LK’ 

INCLUDE  ’DCO:PENS.INC’ 

INCLUDE  ’DCO: RENTABLE. INC’ 

INCLUDE  ’ DCO: EVENTS. INC’ 

Cm  COMMON  BLOCK  ADDED  CCR  ID  FEATURE 

INCLUDE  ’DCO: PEN I DENT. INC' 

c  mtmmmmm  external  functions  referenced  ummmmmm 

PEAL  ENTRY  TINE 

C  TIME  A  FENETPATCP.  ENTERS  THE  RESION  OF  RESPONSIBILITY  OF 

r  H  rvc-n* 

C 

Cm  FUNCTION  ADDED  FOR  ID  FEATURE 
PEAL  UNFRN 

C  A  RANDOM  C= AW  TO  DETERMINE  'HE  ID  CODE 

c  iiiiimtmumiii  .coal  .apiable  definitions  itimiiiutmmiii 

IN'ESEF  I 
IN'ZC-i 
INTESi 


DC  Cnc’  INDEX 
DC  .CCC  INDEX 


"NE'^A'DR  :£TM  ”  CUCFFENT  FENETF.ATCR 
ijcp  -vs r 

-vcc  -up-  PENE'EA’DR 


A— 4 


LGEICAL  FOUND 

C  HAS  THAT  TYPE  OF  PENETRATOR  ALREADY  SEEN  SEEN  AL0N6  THIS  PATH 

Cl*l  ADDED  FOR  ID  FEATURE 

r» 

u 

REAL  ID.PND.VAR 

0  VARIABLE  TO  USE  WITH  ID  CODE 

r 

c  tmmmttmittmmi  executable  code  mmmmtmitmmm 

FOR  ALL  PATHS.  ZERO  OUT  'HE  MUSSES  OF  DENETRATCR  TYPES 

::  :=i..':fa^si 

N_TYPES_FOR_DATH ( I ) =0 
DO  Jsi.’HAx’NUH.PEN.TYPES 
"YPES ~FOR ~PATH ( I . J ) =0 

ENDDO 

rkinng 


ZERO  OUT  THE  PENETRATOR  TABLE 

DC  I  =  1.  NAX.NUN.PENETRATORS 
DO  Z  =  1 .  ~NUS_°EN  TABLE  ENT?.! 
PENJABLE  U.  J!  =0.0 

ENDDO 

ENDDO 


INITIALIZE  THE  PENETPATOR  TABLE.  AND  ESTABLISH  THE  SLOCK  PATHPEN. 

WHICH  STORES  ALL  TYPES  OF  PENETRATOF.S  THAT  “AY  CONE  DOWN  A  SIVEN  PATH. 

DC  I  =  I.  NU.NPE.N 

PEN/ABLE  (I.  EXISTENCE')  =  TRUE 

bcm  ;jt  PENETRATOR  TYPE)  =  PEN  TYP  (!) 

PEN  tABLE  (I.  PENETRATOR  PATH)  =  PEN  PATH  !I! 

ockj  t^bi_c  ;*t  cy;  cwtdv;  =  ENTRY  TINE  (I.  CO.  1) 

TH£  HYS7EN  ENTRY  T!NE  IS  SET  T0  THE  TINE  OF  'HE  FIRST  EVENT  ON 
*ur  cr^rrc;’]!!’ c  cyciji  WHICH  'S  'VPICALLY  EN'RV  INT0 

SCNE  RADAR  CCVERASE  ZCNE. 

FEU  EVENT'!: =0 
-  Em'WhYPCINT : I ! =1 
°EN  *AFEE!!I)=0 

::  :=:.n.wh_tvpe 

FEN. WARHEAD !  I.  j)  =C'EN. SENSE  !FEN."/0 '!;.:) 

INITIALIZE  ruE  ‘L79EF  CF  C?*S  AF^EF'  ^^E  crNETRA72F 
N  10  A F T E P  :EN 


C  POSSIBLY  ADD  TO  THE  LIST  OF  PENETRAT2R  TYPES  ALONG  A  GIVEN  PATH. 


CURR.PATH  =  PEN .PATH  (I) 

:URR*TYPE  =  PEN~TYP  (I) 

FOUND  =  .FALSE." 

IF  (N_TYPES.FEiP.PATH  (CURR.PATH)  .GT.  0)  THEN 
"DO  J  =  1 . ~N.TYPES_FOR.PATH  (CURR.PATH) 

IF  (TYPES .FCR.PATH  (CURR.PATH,  J)  ,E8. 

1  "  ’  CURR  TYPE)  THEN 

FOUND  =  .TRUE. 

ENDIF 

ENDDO 

ENDIF 

IF  (.NOT.  FOUND)  THEN 

N_TYPES.FOR.PATH  (CURR.PATH)  = 

1  N_TYPES.FOR.PATH  (CUPR  PATH)  ♦  1 

TYPES.FOR.PATH  (CURR.PATH,  N_TYPES.FOR.PATH 
1  "  (CURR  PATH))  =  CURR  TYPE 

ENDIF 

C  CLEAR  ECN  TABLES 

DO  J  =  1.  MAX  JAMMED  SITES 
DEN  ECN  (I,  J)  =*0 
ENDDO 

C 

ENDDO 

C 

CIH  CODE  ADDED  TO  INITIALIZE  THE  PENETRATOR  ID  CODES 


DO  I  =  1.  NAX.NUH.PENETRATCRS 

ID.RND.VAR  *  UNFRHtO.,1.,5! 

IF  (ID.RND.VAR  .LE.  0.018)  THEN 
DEN_ IDENT ( I )  =  1 

ELSEIF  (ID.RND.VAR  .LE.  0.00)  THEN 
3EN.IDENT(lf  *  2 

ELSEIF  'ID.RND.VAR  .LE.  0.02 0CS)  THEN 
:EN.!DENT(I)  =  3 

ELSEIF  (ID.RND.VAR  .LE.  0.39416)  THEN 
3EN  IDENT C I T  =  4 


C  SHORT .FIRE 

r 

C  SUBROUTINE  ’SHORT.FIRE’  SIMULATES  THE  SHORT  RANEE  PORTION  OF 

3  THE  MISSION. 

C 

C  ALPHATECH,  INC. 

C  AIR  FORCE  CONTRACT  F33657-B1-C-2150 

C 

cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 


& 


SUBROUTINE  SHORT.FIRE  (TIME,  PEN.  COIF.  PACKED.'JCLASS.  UITEM. 

SUB.F  RE9.N.NEN.F  REQ.NEW_MQDEL.REQ, 
new’ f' req. nen.sub’ F.REQ, T.NEH.F.REQ ) 


IMPLICIT  NONE 

tmtsimtttimmmi  include  common  blocks  mmstmmmmmtt 


INCLUDE  ' DCO: PARAMETER .DIM’ 
INCLUDE  ’ DCO: EXECUTIVE. DIM’ 
INCLUDE  ’DCO: STATESMAN. DIH’ 
INCLUDE  ‘ DCO: COIN  IT. PRfl’ 
INCLUDE  ’ DCO: PENSI . PRM’ 
INCLUDE  ’DCO.-NEPARA.PRM’ 
INCLUDE  ’DCO:COUNIT.INC’ 
INCLUDE  ’DCO: PENS. INC’ 


:ttt  COMMON  BLOCK  ADDED  FOR  ID  FEATURE 
INCLUDE  ’DCO: PEN I DENT. INC’ 

;  mmimmitmm  input  variable  definitions  tuuunmmtmuu 


REAL 

TIME 

2 

CURRENT  TIME 

INTE5ER 

°EN 

PENETRfiTQR  NUMBER 

INTSSER 

COIR 

— 

00  INDEX 

INTE5EF. 

:AC:<£D.L'CLASS 

UNIT  CLASS 

« 

INTSSER 

UITEM 

- 

UNIT  ITEM  INDEX 

INTESER  SUB. c. RED 

SUB "function  RE2UES7  IDENTIFIER 
INTE5ES  N.NEN.F.RE3 

’number  OF  SUBSEQUENT  FUNCTION  REQUESTS 
INTSSER  NEW  MODEL  RE3CMAX  INTERFACE  SIDE) 

MEW  MODEL  REQUESTS 

INTSSER  NEW  F  FED (MAX  INTERFACE  SIZE) 


A-e 


THE  NEW  FUNCTION  REQUESTS 
I  NTE5ER  NEW  JUB.F.RE3 I MAX. I  NTERFACE.S  IZE) 

THE  NEW’SUBFUNCTION  REQUESTS 
REAL  T.NEW.F.REQ(HAX.INTERFACEJIZE) 

THE  SCHEDULING  TINE  OF  THE  NEW  FUNCTION  REQUEST 

mmtmitmmmi  local  variable  definitions  mmmitmmmtt 


CHARACTERS  REPORT 

STATUS  ON  SHOTS  TAKEN  BY  PROSECUTOR 
REAL  TNEXT 

NEXT  ITERATION  TINE 


REAL 

P.SFEED 

PENETRATOR  SPEED 

CHARACTERS  STATUS 

MISSION  STATUS  AT  OUTPUT 

REAL 

VCRUISE 

CRUISE  SPEED 

REAL 

TURN 

UNIT  TURN  RATE 

REAL 

FUEL.TQ.BASE 

fuel'needed  TO  GET  TO  sase 

REAL 

RESID.FUEL 

RESIDUAL  FUEL 

REAL 

URN 

UNIFORM  RANDOM  NUMBER 

REAL 

T.ORIENT 

ORIENTATION  TIME 

REAL 

RANGE 

INTERCEPT  RANGE 

REAL 

ASPECT 

ASPECT  ANGLE 

REAL 

VBH 

WARHEAD  SPEED 

PEAL 

FK 

KILL  PROBABILITY 

REAL 

DIST 

DISTANCE  TO  BASE 

REAL 

JUNK_PVEL!3) 

cruicTPflTQP  VELOCITV _ NEVCC 

REAL 

upcsit; 

UNIT  POSITION 

INTEGER 

OTVC 

PENETRATOR  TYPE 

INTEGER 

UNPACKED  '.'CLASS 

UNIT  TYPE  INDEX 

LOGICAL 

°en_f:re 

PENETRATOR  FIRE  CLA5 

LOGICAL  WEAPGN.'GUND 

DID  WARHEAD  LOCATE  A  WEAPON? 

LOGICAL 

NONE 

WEAPONS  USEE  rLAG 

KILL 

SUCCESSFUL  KILL  FLAG 
REAL  TEKERI 

TIME  OF  PENETRATOR  GEOGRAPHIC  EXIT  FROM  THE  RESIGN 
CHARACTER! (UNIT.CLASS.STRIN6.LEN6TH)  P.UCLASS.STRINS 
THE  TEXT  'ORM  OF  UNIT  CLASS  * 

ititmmmmt  external  functions  referenced  mmmiitmitmtt 


REAL 

L'NFRfl 

RETURNS  UNIFORM  RANDOM  VARIABLE 

REAL 

PEN  KILL 

RETURNS  PENETRATOR  KILL 

REAL 

NEAREST.SASE 

RETURNS  NEAREST  BASE  DISTANCE 

INTEGER 

P  TYPE 

RETURNS  PENETRATOR  TYPE 

REAL 

EXIT.TIME 

THE  EXIT  FROM  A  REGION  FUNCTION 

LOGICAL  TRACE.DN 

TRACE  ON  FLAG 

C.HARACTERI32  DESCRIBE.STATUS 

CONVERTS  INTERNAL  STATU5  INTO  STRING  FOR  OUTPUT 
CHARACTER! (UNIT.CLASS.STRING.LEN6TH)  UNIT.CLASS.STRING 
THE  FUNCTION  THAT  ASSIGNS  P.UCLASS.3TRIN6 

!l!!!!!!!!l!!!l!l!!!!!l!  EXECUTABLE  CODE  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

IF  ;TPACE.0N  (!)  THEN 

SIR ITE  :TRACEFILE.  1)  ’  ’ 

WRITE  (TRACEFILE,  I)  ’INPUT  VARIABLES  FOR  SUBROUTINE 

’ SHORT_FIRE’ 

WRITE  ( TPACEFI LE.  !)  ’TIME’, TIME 
WRITE  (TRACEFILE,  I)  ’PENE7RAT0R’ .PEN 
WRITE  iT’ACEFILE.  I)  ’CURRENT  COKCOIP 
°_L’CLASS_STRING  =  IJM I  T_^LASS_STR  I N5  X  CO  I F .  PACKED  _'JCLA3S , 


PACKED) 


WRITE  (TRACEFILE,  !)  ’UNIT  CLASS’.  P.UCLASS.STRINS, 

’UNIT  ITEM’.UITEM 

ENDIF 

TEXEF I=ET IT  ’IME'FEN.CD.COIP: 

REF :RT«N2NE 'status 

UNPACKED  UCLASS  -  CO  UNIT  TYPES  (COIF.  PACKED  UCLASS; 


SET  PENETRATCF  ’VPE 

prvo  =  c  fysc(pc»|j 

EET  ’’JRN  PATE 

TURN  *  TURN  : ATE (UNPACKED  UCLASS) 


C  SET  SPEED 


n 

u 

VCRUISE  =  CRUISE  SPEED (UNPACKED  UCLASS) 

C 

C  SET  POSITION 

CALL  UNIT_KINE?1  (TIME.COIP. PACKED_'JCLASS. UITEM, 'JPGSJ 
DI3T  =  NEAREST  BASE (COIP.UPOS) 

FUEL.TO.SASE  =  DIST/VCR'JISE 
PESID.FUEL  =  (FUEL.TOJASE  *  PI/TURN)  I 
+  "  CRUISE_TO_FI£HT  CJNPACKED.'JCLASS) 

C  REPORT  RESULTS  SO  FAR  IF  TRACE  IS  ACTIVATED 

D  IF  (TRACE.ON  !))  THEN 

D  NRITE’tTRACEFILE.  «!  ’PENETRATOR  TYPE’.PTYP 

D  WRITE  (TRACEFILE.  I)  ’FI  CRUISE  SPEED’.  VCRUISE 

D  WRITE  (TRACEFILE.  t)  'UNIT  POSITION’. UPOS 

D  WRITE  (TRACEFILE.  *)  'DIET  TO  BASE’.DIST 

D  WRITE  (TRACEFILE.  I)  ’FUEL  TO  BASE’ ,FUEL_TO_SASE 

D  WRITE  (TRACEFILE.  *)  ’RESIDUAL  FUEL’. RESID  FUEL 

D  END  IF 

C 

C  SET  REFERENCE 

U 

CALL  SET.REFf TIKE.  UPOS.  COIP. PACKED  JJCLASS,  UITEM! 

C»l  BEFORE  ALLOWING  FOR  ATTRITION  DETERMINE  IF  UNKNWOWN 
Cm  INTERCEPTS  ARE  FRIENDLY  OR  HOSTILE 
CHI  CODE  ADDED  FOR  IDENTIFICATION  INTERCEPT 

w 

C»t  IF  UNKNOWN  FRIENDLY  THEN  SET  STATUS  TO 
cm  NISSJTAT’JS  TO  FREE  CO  AND  CHANGE  ID  TO 
cm  CODE  (3)  T0  PREVENT  FUTURE  PROSECUTION 

IF  (PEN.IDENT  (PEN)  .ES.  1  !  THEN 
TNEXT  =  TINE 
STATUS  =  NISS.STATUS 
°ENJDENT(PEN)  =  a 
GO  TO  CCO 
END  IF 

CII*  END  CCDE  FOR  IDENTIFICATION  INTERCEPT 

C  ACCCUNT  FCR  ATTPITION 

URN  =  UNF5N!0.,1.,5) 

IF  (URN  .ST.  0.5)  THEN 
PEN  FIRE  -  .TRUE. 

ELSE 


PEN  FIRE  =  .FALSE. 


FENETRATDR  FIRES  FIRST 


IF  (PEN.FIRE)  THEN 

PK  =  PEM_K  ILL  (PTYP .  ’JNPACKED_UCLAS3 ) 

CALL  SIH.ENGIPK.KILLJ 
IF  (TRACE'.QN  0)  THEN 

WRITE  (TRACEFILE.  »)  ’PESETRATDR  FIRING  FIRST  AT  FI’ 

WRITE  (TRACEFILE,  t )  ’PK’.PK 

WRITE  (TRACEFILE,  »)  ’FI  KILLED?’,  KILL 

ENCIF 

IF  'KILL!  THEN 

CALL  WEA_DEADTTI«E.COIP.PACKED_UCLASS,UITEM) 

TNEXT  =  TINE 

IF  (UNIT.STAT  (COIR,  PACKED JJCLASS,  UITEN) 

.EQ.  UNIT.DEAD  STATUS)  THEN 

STATUS  =  UN  I  T_DEAD_3T AT'JS 
SO  TO  200 
ENDIF 

ENDIF 

ENDIF 

FI  ATTACKS 

REPORT*  FIRE.STATUS 
RANSE  =  0 

CONFUTE  ASPECT  ANGLE 

ASPECT  =  UNFRN(0.,PI,5) 

GET  WARHEAD  AND  SIMULATE  ENGAGEMENT  OUTCOME 

CALL  WARHEAD  (COIR,  PACKED  JJCLASS,  UITEN,  PTYP.  RANGE.  ASPECT. 

+  .TRUE..  VWH.  RK.  WEAPON.FQUND,  NONE) 

IF  (.NOT.  WEAPCN.FOUND)  THEN 

WRITE  (ERROR *CILE.  I)  ’ERROR  IN  SHQRT.FIRE’ 

WRITE  (ERROP"_:ILE.  I)  ’WARHEAD  DID  NOT  LOCATE  A  WEAPON’ 

CALL  UERR  (FATAL) 

ENCIF 

IF  OUT  OF  WEAPONS.  THEN  RETURN  TO  SASE 
IF 'NONE)  T^EN 

UNIT.STAT  (COIF.  PACKED  LCLASS.UITEM:=  rASE.STAT’JS 

ENDIF 

CALL  SIM.ENG(PK.KILL) 

IF  (TRACE.ON  (!)  THEN 

WRITE  (TRACEFILE.  «)  ’CI  ATTACKS’ 


D  WRITE  (TRACEFILE,  »)  ’WARHEAD  SPEED’,  VWH 

D  WRITE  'TRACEFILE,  I)  ’SALVO  PK’.PK 

D  WRITE  (TRACEFILE,  I)  ’PENETRATOR  KILLED?’.  KILL 

D  WRITE  (TRACEFILE,  »)  ’WEAPONS  DEPLETED’.  NONE 

D  ENDIF 


C 

C  PENETRATOR  DESTROYED 


IF  (KILL)  THEN 

TNEXT  =  TINE 
STATUS  =  DEAD.STAT'JS 
GO  TO  OOO 


C  IF  MISSED  CHECK  FUEL  AND  UPDATE  DESTINATION 


ELSE  IF  ( FUEL.R !CQIP, PACKED_UCLASS, UITEN!  .EE.  RES1D.FUEL)  THEN 

r* 

w 

C  IF  NO  WEAPONS  SEND  TO  BASE 

IF  (NONE)  THEN 

D  IF  (TRACE  ON  0)  THEN 

D  WRITE  (TRACEFILE,  I)  ’FI  OUT  OF  WEAPONS,  ’. 

D  +  ’RETURN  TO  BASE’ 

D  ENDIF 

TNEXT  *  TINE 
STATUS  *  BASE  STATUS 

UNITSTAT ICOIP,  PACKED_UCLASS,  UITEH)  =  BASE.STAT'JS 
GO  TO  200 

ENDIF 

C  CHECK  PENETRATOR  SPEED 

P.SPEED  =  PE!»_SPEED(PEN.TYP(PEX)) 

C 

C  INFEASIBLE 

IF  (P.SPEED  .ST.  DASH.SPEED (UNPACKED JJCLASS)!  THEN 
TNEXT  =  TINE 
STATUS  =  HISS. STATUS 
SO  TG  200 

ENDIC 


C  FEASIBLE  FOR  REENGAGEMENT 


STATUS  =  SHORT. STATUS 
C  CONFUTE  ORIENTATION  TINE 


URN  =  UNFRM-O. .FI.5) 
T  ORIENT  =  URN/ TURN 


SET  UNIT  AT  PENETRATCR 


TNEXT  =  TINE  +  T_QRIENT 

CALL  PEN_KINEH (TNEXT, PEN, UPOS, JUNK_PVEL) 

UPDATE  DESTINATION 

CALL  SET_DES  (TNEXT,  UPOS,  COI P ,  PACKED_UCLASS .  'J I  TEN) 
NOT  ENOUGH  FUEL  TO  REEN6A6E 
ELSE 


SET  UP  THE  CONTROLLER  RELEASE  AND  RETURN  TO  BASE 
TNEXT  =  TINE 

UNIT.STAT  (COIP.  PAC,,ED_UCLASS.  UITEN)  =  9ASE_  STATUS 
STATUS  =  BASE.STATUS 
GO  TO  200 
END  IF 

PENETRATGR  FIRES  SECOND 

IF  (.NOT.  PEN.FIRE!  THEN 

PK  =  PEN_KILL (PTYP, PACKED_UCLA3S) 

CALL  SIM_ENG(PK, KILL.) 

IF  (TRACE'.ON  0)  THEN 

WRITE  (TRACEFILE,  I)  ’PENETPATOR  FIRING  SECOND  AT  FI 

WRITE  (TRACEFILE.  I)  ’PK’.PK 

WRITE  (TRACEFILE,  *)  ’KILL  OF  FI  BY  PENETRATDR' . KILL 

ENDIF 

IF  (KILL)  THEN 

CALL  WEA  DEAD! TIME, COIP. PACKED  'JCLASS, UITEN) 

TNEXT  =  TINE 

IF  (UNITJTAT  (COIP, PACKED.UCLASS, UITEN)  ,EQ. 

1  UNITJEADJTATUS)  THEN 

STATUS  *  UNIT.DEAD.STATUS 
50  TO  200 
ENDIF 

ENDIF 

ENBI' 

COiriNUE 


IF  !TRACE_QN  0)  THEN 

WRITE* (TRACEFILE.  t)  ’FINAL  STATUS  IN  SUBROUTINE  ’, 

►  ’SHORT  'IRE:  ’.  DESCRIBE  STATUS 

ENDIF 

CANCEL  ALL  MISSIONS  FOR  ALL  UNITS  ASSIGNED  TO  A  PENETPATOR 
IF (STATUS. £Q.  DEAD  STATUS)  THEN 


FREE_CO_AFTER_PEN  HILL  DISENGAGE  ALL  UNITS  IN  ALL  CO’S 
PURSUING  THIS  PENETRATCR 

N_NEW_F_REQ=N_NEW_F_REQ+! 

NEW.flQDEL.REQ  Fn.NEW.F.REB) =PRQSECUTE_HODEL 

nen*f.reqIn.nem’f.req)=prinitive.«odel 

NEN.SUB  F_RE9(N_NEN_F_REB)=FREE_C0_AFTER_PEN_N0DEL 
t.neh.f'req (N.NEW.F.REQ i =TNEXT  * 

NOTIFY  THE  NETWORK  OF  PENETRATOR  CANCELLATION 

N_NEW_F_PEQ=N_NEW_F_REQ+1 
NEW_«GDEL_RE3(’N_NEW>_RE3)=NETi<0F:K_r-GDEL 
NEW_F_REq1n_NEV)_F_REG)  =TERH_PEN_!1DDEL 
NEN.SUB  F.REQfN  NEW_F.RE3)=0 
T.NEW.f'rEO (N.NEW.F.REQ) =TNEXT 

COLLECT  DESTRUCTION  STATISTICS 

N.NEH.F  RE3=N.N£W.F_REQ+1 

NEW.NQDEL  REQIN.NEW’f  REfl!=STATISTICS  ENTRY.MOCEL 

NEW_F.REO"(N_NEW*F_REQ)=TERH_STATS_MODEL 

NEW  SUB  F  REQfN  NEN  F  REQ) =0 

T_NEW_F_REG (N_NEW_F_RE3) =TNEXT 

DISENGAGE  UNIT  FOR  HISSES 

ELSE  IF (STATUS. EQ.  HISS.STATUS)  THEN 

FREE  THIS  CO  ONLY  FROM  PURSUIT 

N.NEN.F  RE3=N_NEW_F.RE3+1 
NEN.MQDEL_REQ(N.NEVf_REQ) -PROSECUTE  MODEL 
NEW.F.REG (N.NEW.F.REQ) =PRIMITIVE_MODEL 
NEN.S'JB.F.Re’B(N.NEN.F.RE3)*FREE.0NE_C0.AFTER.PEN.MQI!EL 
T.NEN.F.REQ (N.nIw.F.rIq) =TNEXT 

HANDOVER  FOR  ESCAPES  --  TEXERI  =  0  IFF  THE  PENETRATOR  HAS 
50TTEN  OUT  OF  REACH  OF  THIS  CO 


IF  PE.N.IEENTIPEN)  ,E0.  3)  THEN 
'NEXT  =  TEXERI 

END  IF 

IFCEXERI.ST.O.O)  THEN 
N.NEW_F_RE3=N_MEW_F_RE3+1 
NEH.M0DEL.RE3’(N.NEn"c.RE3!=NEtNGRK.M0DEL 
NEN.F.RE3(N.NEN_F.RE0f=LCAD.3UEUE.M0DEL 
NEw”sUB_F_6Eu In"nEX_F_5E9) =0 
’  NEW  c  REO'N  NEW  F  F:E3!=TNEXT 


N  NEW  F_RE3=N  NEW  F_RE2+1 
NEWJ0DEL.REQ(NJEW.F.REQ)=NETWQRK.*1QDEL 
N£w"f_REq1  N.NEW'.F.REQ)  =HANO  .OVER .MODEL 
NEwjuB_F.REQ!N_NEW_F_REa)=0 
T_MEW  F_R£Q  CN_MEW  F.REQ)*TN£XT 
ENDIF 

FREE  SERVER  NOW 

ELSE  IF (STATUS.EQ.  UNIT_DEAD_STATUS)  THEN 

FREE  this  CO  ONLY 

N_NEy_F_REQ=N_NEK_F_REQ+l 

NEWHQDEL  REQ (N.NEW j.REQ ) =PROSECUTE_HQDEL 

new.f_reg]n_nen"f_peq)sprimitive_nobel 

NEW_5UB_F_REa  (N_NEW_F_REQ)  =FREE_QNE_C0_AFTER_PEN_!10DEL 
T.NEWj’rEQ  (N.NEW.f’rEQ  )  =TNEXT 

LOAD  QUEUE  MODEL  FOR  DEAD  UNITS 

IF (TEXERI. ST.O.O)  THEN 

N  NEW  F_REQ=N  NEW_F_REQ+1 

NEW  model.req1n_new*f.req)=network.model 

NEW>  REOfN  NEW  F  REQ)=LQAD  QUEUE.NODEL 
NEW  SUB.F.REQtN  NEW_F_REQ) =0 
T  NE'W  F  REQ  (N  NE*W  F  REQ)=TINE 
ELSE 

N_NEW.F_REQ=N_NEW.F_REQtl 
NEH_*10DEL_REq7n_NEW_F_REQ)  =NETWORK_nODEL 
neh_f_reqTn_neh~f_reqT =HAND_OVER_MDDEL 
NEw'sUB.F.REQ (N _NEH_F_REQ) =0 
T.NEW  F*REQ(N  NEW  F*REQ)=TINE 
ENDIF 

FREE  SERVER  AND  RETURN  UNIT  TO  BASE 
ELSE  IF (STATUS.EQ.  9ASE.STATUS)  THEN 
FREE  THIS  CO 

N.NEW.F  FE2=N_NEW  F.FEOi 

NEW.MODEL  REQ(N.NEW>_RE3)=PR0SECUTE.“0DEL 

NEM_F_REq1n_NEW~F_RE3T=PRIMITIVE_Y!0DEL 

NEI#2sUB_F_REQ  (N.NEW.F.REQ)  =FREE_ONE_CC_AFTER_REN_MC'BEL 

T.NEW.fYeO  !N.NEW.f’rEQ)=TNEXT  ' 

LOAD  THE  QUEUE  FOR  A  RETRY  FOR  PROSECUTOR  TERMINATED 

IF (TEXERI. ST. 0.0)  THEN 

*nEW_F_REQ=N_NEN_r_RE!M 

NEW  MODEL  REo’fN  NEW  c  FED)  NETWORK  MODEL 


NEN_F_RE8(N_NEN_F_RES)=L3AD_3UEUE_NDDEL 
NEM_SUB_F_REQ CN_Nin_F_REQ) =0 
T  NEW  f'rESIN  NEW  FREQ) =TNEXT 
ELSE 

N_N£W_F_REQ=N_NEW_F_R£Q+1 
NEW_!1QDiL_REQ  Fn_NEW~F_RE3)  =NETWORK_«QDEL 

new_f_peq1n_sew_f_reqT =hand_over_mqdel 

MEW_SUB_F_REQ (N_NEW_F_REQ) =0 
T  NEW  F* RESIN  NEW  F  REQ) =TNEXT 
ENDIF' 

OTHERWISE  THE  STATE'S  IS  SHORT  STATE'S 


NNEW  F_RE9=N_NEW_F_REQ+1 
NEW  H0DEL.RE3 7n_NEW_F_REQ)  =PR0SEC'JTE_f10DEL 
NEW_F_RE8<N,NEW_F_R£Q)=C0_£N6  MODEL 
NEW  "SUB  F  REQIN  NEW.F  REQ)"=SHORT  fire  model 
T  NEW  F  REQ (N  NEW  F  REQ)=TNEXT 
ENDIF" 

IF (REPORT. E3.  FIRE.STATUS)  THEN 

SCHEDULE  EN6A6EMENT  STATISTICS  COLLECTION  ROUTINE 


N_NEW_F_REQ=N_NEW_F_REQ+1 
NEW  MODEL.REqTn  NE'w'f  REQ) ^STATISTICS  ENTRY  MODEL 
NEM_F_REq7n  NEW  F  REQUIRE  MODEL 
■NEW_SUB_F_REQtN_NEW_F  REQ)=0 
T  NEW  F  REQ (N  NEW  F  REQ) =TIM£ 


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 


V 

i  * 


LCN6.FIRE 

SUBROUTINE  ’L0N6  FIRE’  CONDUCTS  THE  LONS  RANGE  FIRING. 


ALf'HAT ECH.  INC. 

AIR  FORCE  CONTRACT  F33657-9 l-C-2150 


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 

c 

SUBROUTINE  LQNG.FIRE (TIME, PEN, COIR, PACKED JJCLAS5, U I TEN,  SERVER. 

•s  SUB.F.RE3,N.NEN.C.REQ'NEN  MQDEL.REQ, 

&  NEW_F_REQ,NEW_SUB_F_REQ,T~NEM_F_REQ} 


IMPLICIT  NONE 

ttimimmmmmtt  include  common  blocks  iiimmttmimmtiu 


INCLUDE  ’DCO: PARAMETER. DIM’ 
INCLUDE  ’DCOjEJECUTIVE.DIM’ 
INCLUDE  ’DCO:STATUSNAM.DIM’ 
INCLUDE  ’DCO:COINIT.PRM’ 
INCLUDE  ’DCO: WEPARA.FRU’ 
INCLUDE  ’ DCO: FIRERANSE. BLK’ 
INCLUDE  ’ DCOsCOSERV. INC’ 
INCLUDE  ’DCO: COUNIT. INC’ 


C*»»  COMMON  SLOCK  ADDED  FOR  ID  FEATURE 
INCLUDE  ’ DCO: PENIDEHT. INC’ 

c  mmmmmmm  input  variable  definitions  tmmmmmmmt 


REAL 


time 

CURRENT  TIME 
INTEGER  FEN 

PENETRATOR  NUMBER 
INTEGER  CO IP 

00  INDEX 

INTEGER  PACKED  JJCLASS 

UNIT  TY»E  INDEX 
INTEGER  UITEM 

UNIT  ITEM  INDEX 
INTEGER  SERVER 

SERVER  CONDUCTING  THIS  ENGAGEMENT 
INTEGER  SUB  c  RE3 

SUB* FUNCTION  REDDEST  IDENTIFIER 
INTEGER  N.NEW.F.REQ 

NUMBER  OF  SUBSEQUENT  FUNCTION  REQUESTS 
INTEGER  NEW.M0DEL.PE3 (MAX. INTERFACE .SITE) 

NEW  MODEL  REQUESTS 


A-  i : 


INTEGER  NEW_F_RE3 (SflX_IMTERFACE_5I2E) 

THE  NEM  FUNCTION  REQUESTS 
INTEGER  NEW_S’JB_F_REQ(HAX_INTERFACE_5IZE) 

THE  HEN  SUBFUNCTION  REQUESTS 
REAL  T.NEN.F.REQfNAXJNTERFACE.SIZE) 

THE  SCHEDULING  TINE  OF  THE  HEN  FUNCTION  REQUEST 


tttmtmtmmtim  local  variable  definitions  mttmmttmxum 

LOGICAL  SUCF 

SUCCESS  flag  on  weapons  selection 
REAL  TNEXT 

NEXT  ITERATION  TINE 
OHARAOTERI4  STATUS 

STATUS  VARIABLE  cOR  RETURN  DIRECTION 
REAL  RAD.RANJINE 

TINE  PENETRATOR  IN  RADAR  RANGE 
REAL  VUNIT 

UNIT  SPEED 
REAL  CON  RAT 

UNIT  FUEL  CONSUMPTION  PATE 
REAL  VCRUISE 

UNIT  CRUISE  SPEED 
REAL  P.R 

AUTONOMY  ;ANGE 
REAL  TPRINE 

TEMPORARY  TIME  VARIABLE 
REAL  R.R.TO 

RADAR  RANGE  TINE  VARIABLE 
REAL  R.R.T1 

RADAR  RANGE  TINE  VARIABLE 
REAL  TEX 

EXT  TINE 
REAL  PP 

DISTANCE  SQUARED 
REAL  TINT 

INTERCEPT  TINE 
REAL  DIST 

DISTANCE 
REAL  FUEL  NEED 


-ENAININS  FUEL 
REAL  RANGE 

INTERCEPT  RANGE 
REAL  VAG 

VELCCHY  NAGNITUCE 
REAL  ASPECT 

ASPECT  ANGLE 
REAL  VWH 

WARHEAD  SFEED  Ji 


REAL 


KILL  PROBABILITY 
R.MAX 

MAH  I HUM  FIRING  RANGE 
.06ICAL  WEAPON.FQUND 

DID  WARHEAD  FIND  A  WEAPON  TO  USE? 

REAL  TWH  INT 

WARHEAD  INTERCEPT  TIME 
REAL  TEHP 

TEMPORARY  VARIABLE 
SEAL  PROS (3) 

PENETRATOR  POSITION 
REAL  PVELI3) 

PENETRATOR  VELOCITY 
REAL  UPQSI3) 

UNIT  POSITION 
REAL  UVEL13) 

UNIT  VELOCITY 
REAL  DELP (3) 

RELATIVE  POSITION 
SEAL  EST  INT_POS (3) 

ESTIMATED  INTERCEPT  POSITION 
REAL  DEL.P0SI3) 

RELATIVE  POSITION  TO  INTERCEPT 
INTEGER  UNPACKEDUCLASS 
UNIT  TYPE  INDEX 
INTEGER  I 

DO  LOOP  INDEX 
INTEGER  PTYP 

PENETRATOR  TYPE 
LOGICAL  FLAG 

CONTINUE  FLAG 
LOGICAL  NONE 

WEAPON  EXHAUSTION  FLAG 
LOGICAL  KILL 

KILL  FLAG 
CHARACTERS  REPORT 

REPORT  STATUS  ON  SHOTS  ASA  INS  A  PENETRATOR 

tttmmmmtmtmtt  function  definitions  mmmtmmmmm 

PEAL  EXIT_TIME 

RETURNS  EXIT  TIME 
PEAL  INNES.PRODUCT 

RETURNS  INNER  PRODUCT 
PEAL  NEAPEST.BASE 

RETURNS  DISTANCE  TO  NEAREST  BASE 
.PEAL  NEX7.WAY .POINT 

RETURNS  NEXT  WAYPOINT  TIME 
INTEGER  P.TYPE 

RETURNS  PENETRATOR  TYPE 
CHAPACTEP.I!'  DESCRIBE. STATUS 


CALL  VSUB J PPOS, UPOS, DELP) 

?P  =  INNER.PRODUCT (DELP, DELP) 

RANGE  =  SGRT(PP) 

IF  (TRACE.QN  0)  THEN 

WRITE  (TRACEFILE,  *)  ’CURRENT  RANEE  RANEE 
ENDIF 

IF  {RANEE  .LT.  SHORT.RANGE!  THEN 
TNEXT  =  TIME 
STATUS  =  SHORT.STATUS 
30  TO  200 
ENDIF 

COMPUTE  UNIT  INTERCEPT  TIME 

CALL  INTERCEPT JIME (TIME, PPOS, UPOS, PVEL,VUNIT, TINT, FLAB) 

CHECK  FLAB  TO  DETERMINE  IF  INTERCEPT  IS  PHYSICALLY  POSSIBLE 

IF  (.NOT.  FLAG)  THEN 
TNEXT  =  TIME 
STATUS  =  MISS.STATUS 
30  TO  200 
ENDIF 

NOW.  CAN  INTERCEPT  OCCUR  BEFORE  THE  PENETRATOR  LEAVES  THIS  CO 

TEX  *  EXIT  TIME(PEN,CO,COIP) 

IF  (TRACE  ON  !))  THEN 

WRITE  (TRACEFILE,  *)  'EXIT  TIME’,  TEX 
ENDIF 

IF  (TEX  .LT.  TINT)  THEN 
TNEXT  =  TIME 
STATUS  =  MISS.STATUS 
30  TO  200 
ENDIF 

CHECK  FUEL  FEASIBILITY 
DO  I  =  1.3 

SET  ESTIMATED  INTERCEPT  POSITION 

EST.INT.POS! I)  =  PPOStI)  +  PVEL(I) KTINT  -  TIME) 

COMPUTE  RELATIVE  POSITION 

DEL.PQS ! I !  =  EST.INT.POS! I)  -  UPQS(I) 

SNDDO 

IF  (TRACE. ON  !))  THEN 

WRITE  (TRACEFILE.  t!  'ESTIMATED  INTERCEPT  POINT’, 

*  EST.INT  ROE 


COMPUTE  REQUIRED  FUEL 


PP  =  INNES_PRODUCT(DEL_PQS,DEL_POS) 

DIST  =  NEAREST _BASE (Cofp, EST_INT_POS) 

FUEL.NEED  =  CGN_RAT tSBRT (PP) /VUNIT  ♦  DIST/VCRUISE 
T.FUEL  =  FUEL_R (CO  IP, PACKED.UCLASS , U I TEM) 

C  CHECK  FEASIBILITY 

IF  (T.FUEL  .LT.  FUEL.NEED)  THEN 
TNEXT  =  TINE 

UNIT.STAT ! COIP, PACKED. UCLASS,U ITEM!1  BASE.ST  AT’JS 
STATUS  =  HI5S.STATUS 
GO  TO  COO 
END  IF 

C  SET  DESTINATION 

CALL  SET.3ES (TINT, EST.INT_POS.COJP, PACKED.UCLASS, UITEN) 

C  SET  UNIT  VELOCITY 

DO  I  =  1.3 

IF  (TINT  .NE.  TIME!  THEN 

UVELU)  *  DEL  PQS  £  I )  /  (TINT  >  TIME) 

ENDIF 

ENDDO 

C 

C  CHECK  WAYPOINTS 

TPRIHE  =  NEXT.WAY .POINT (TIME, PEN) 

C  SET  RADAR  RANGE  TINE 

IF  (PP  .NE.  0)  THEN 

R.R.TO  =  TINE  -  (I  -  RR/SQRT (PP) ) I (TINT  -  TINE) 

ENDIF’ 

R.R.T!  =  MAX  (R.R.TO,  TINE) 

C  MODIFY  RADAR  RANGE  TINE  BASED  ON  WAYPOINTS 

IF  IS  R  T!  ,LE.  TPRIHE)  THEN 
RAD'rANJINE  =  R.R.T  1 

C  BASED  ON  CONTROL  POLICY,  FREE  THE  SERVER: 

I F  ( CONTROL  i  CO  I F ,  PACKED  _'JCL  ASS ,  J I  TEN ) .  E2.  LCOSE.STAT'JSi  THEN 
IF!CO. SERVER  REN "(COIR,  SERVER ).E3. FEN)  'HEM 
STATUS1  FFEE.STATUS 
TNEXT=RAD.RAN_TI.NE 
GO  T0  COO* 


m 


RAD.RAN  TIME  =  LARGE  REAL 
ENDIF 

r» 

C  COMPUTE  ASPECT  ANGLE 

VMA6  =  SQRT!INNER_PRODUCT!PVEL,PVEL) ) 

IF  IVHAG  .NE.  0)  THEN 

TEMP  =  !NNER_PRODUCT (UVEL.PVEL) / (VUNITIVMAG) 

if  ;abs  (tempi"  .lt.  i.o>  then 

ASPECT  =  ACCS (TEMP! 

ELSE 

ASPECT  =  ACOS!TEMP/ABS!TEMP) ) 

ENDIF 

ELSE 

ASPECT  =  0 
ENDIF 

C  GET  FIRE  RANGE 

CALL  FIRE.RAN6E  (COIP,  PACKED.UCLASS,  UITEK,  ASPECT, P.m , VNH) 

C  EXTRAPOLATE  THE  PENETRATOR  POSITION  TO  WARHEAD  IMPACT  TIME 
DO  1*1,3 

DELP ! I ) =DELP ( I ) +PVEL ! I ) IR  MAX/VWH 
ENDDO 

PP=INNER_pRODUCT (DELP. DELP) 

°P  =  SQRTtPP!  -  PROSEC.DELTA 
IF  !PP  . 5T .  R_«flX)  THEN 

CALL  F1RE*TIME! TINE, PROS, UPCS.PVEL.VWH.R  MAX, TINT, TNEXT.SUCF) 
IF(SUCF)  THEN 

STATUS  =  LONG  STATUS 
ELSE 

STATUS*  SHCRT.STATUS 

ENDIF 
GO  TO  200 
ENDIF 

Cl**  BEFORE  FI  RE!. 16  AT  A  DISTANCE.  ADD  CODE  T0  SIMULATE 

cm  :oent:ficaticn  intercept.  ccrce  to  shortrange  if 

cm  ID  IS  UNKNOWN 


IF  ( PEN_I DENT ( PEM)  .LT.  3)  THEN 

CAL-  FIRE  .TIME  (TIME.  PROS.  UPOS.  FUEL,  VWH.  SHORT.RANC-E, 
►  "  TINT,  TNEXT,  SL'CF! 

STATUS  =  3H0RT.STATUS 
GO  TO  200 


cm  END  ADDED  CODE  FOR  ID 

r 

C  SIMULATE  FIRING  AT  A  DISTANCE 
C 

PTYP  =  P.TYPE(PEN) 

CALL  WARHEAD  (COIP,  PACKED.UCLASS,  UITEM,  PTYP,  PP,  ASPECT, 

+  '  .FALSE.,  VNH,  PtC,  WEAPON.FOUND,  NONE) 

D  IF  (TRACE.ON  0)  THEN 

D  WRITE'iTRACEFILE,  1)  ’RETURNS  FROM  WARHEAD’ 

D  WRITE  (TRACEFILE,  I)  ’  WEAPON  FOUND  =  ’,  WEAPON.FOUND 

D  IF  (WEAPON.FOUND)  THEN 

D  WRITE  (TRACEFILE,  I)  ’  WARHEAD  VELOCITY  =  ’,  VNH 

D  WRITE  (TRACEFILE,  I)  ’  PK  -  ’.  °K 

D  WRITE  (TRACEFILE,  *)  '  WEAPON  EXHAUSTION  =  ’,  NONE 

D  ENDIF 

D  ENDIF 

C  IF  NOT  SUCCESSFUL,  TRY  SHORT  FIRE 
IF  (.NOT.  WEAPON.FOUND)  THEN 

CALL  F1RE.TIME  (TIME,  PPOS.  UPOS.  PVEL.  VNH.  SHORT  RANGE, 

+  TINT,  TNEXT,  SUCF) 

C 

C  FIRE  TIME  DETERMINES  WHEN  A  SHORT  FIRE  CAN  OCCUR  (AT  TIME  TNEXT! 

C  BASED  ON  THE  SHORT  FIRING  RANGE  SHORT  FIRE. 

C 

STATUS  =  SHORT  STATUS 
SOTO  200 
ENDIF 

r> 

C  IF  OUT  OF  WEAPONS.  SIENAL  RETURN  TO  BASE 
IF (NONE)  THEN 

UNIT.STAT ( COIP, PACKED.UCLASS, UITEM) =  BASE.STATUS 
ENDIF 

C  COMPUTE  WARHEAD  INTERCEPT  TIME 

w 

CALL  INTERCEPT.TIMEITIME, PROS, UPOS. PVEL, VWH.TWH.INT. FLAG) 

D  IF  (TRACE.ON  U!  THEN 

D  WRITE* (TRACEF!LE.  I)  ’RETURNS  FROM  INTERCEPT _TIME’ 

D  WRITE  (TRACEFILE.  I!  ’  WARHEAD  INTERCEPT  TIME  ’.  TWH  INT 

D  WRITE  (TRACEFILE.  t)  ’  SUCCESSFUL  INTERCEPT  ’.FLAG 

D  ENDIF 

C 

C  CHECK  FLAG 

w 

IF  (.NOT.  FLAG)  THEN 
C  SET  DESTINATION 


TNEXT  =  TINT 


iS 


>A 


8 


STATUS  =  SHORT.STATUS 
SO  TO  200 
END  IF 

REPORT*  FIRE  STATUE 


GET  UNIT  POSITION  AT  IMPACT  TINE 


CALL  UNIT.KINEM!TWH.!NT,C01P,PACK£D.UCLASS, UITEH,UPDS) 


SIMULATE  KILL 


CALL  SIff_ENG(PK,  KILL! 

IF  (TRACE.DN  !))  THEN 

WRITE  (TRACEFILE,  I)  ’RETURNS  FROM  SIM.ENS’ 
WRITE  (TRACEFILE,  I!  ’  EFFECTIVE  PK  =  ’,  PK 
WRITE  (TRACEFILE,  I)  ’  SUCCESSFUL  KILL  ’,  KILL 
ENDIF 


IF  (KILL)  THEN 


UPDATE  PENETRATOR  STATUS 


STATUS  =  DEAD.STATUS 
TNEXT=TWH  INT 
ELSE  IF  (NONE)  THEN 
STATUS  *  BASE.STATUS 
TNEXT  *  TWH  INT 

ELSE 

STATUS  =  L0N6.STATUS 
TNEXT  =  TWH. INT 
ENDIF 
CONTINUE 


IF  (TRACE.ON  0)  THEN 

WRITE  (TRACEFILE,  I)  ’FINAL  STATUS  IN  SUBROUTINE  ’, 

+  ’LONGFIRE:  ’,  DESCRI8E.STATUS  (STATUS) 

ENDIF 


FREE  THE  SERVER  AND  RETURN  HERE 


IF (STATUS. ED.  FREE  STATUS)  THEN 


FREE  SERVER  MODEL 


N_NEW.F.REQ=N.NEW.F.RE9+! 
NEW.M0DEL.RE3(N.NEW.F.RE9)=PR0SECUTE.‘,0DEL 
new* f.rebI n.new.f.req] =PRIMITIVE_MODEL 
NEW. SUB  F  RE3(N.NEW.F.REQ)=FREE.SERVER.M0DEL 
T  NEW  f'rEQIN  NEW  F  REQ)=TNEXT 


RETURN  T0  LONG  FIRE  AT  RADAR  RANGE  TIME 


A-I  i 


.1  ■  I 


N_NEW_F_RE9=N_NEW  F.RE9+1 

NEW  MODEL  RE9  (N_NEW_F_REa )  =PRQSECUTE_(10DEL 

ne»_f_req7n_ne«_f_reqT=co_en6_mqdel 

NEW_SUB_F_REQ(N_NEW_F_REQ)"=L0N6_F!RE_M0DEL 

t_nem_f”req  (n_new_f_req  >  =tne:<  t 

SEND  FI  TD  BASE 

ELSE  IF (STATUS. £Q.  BASE.STATUS!  THEN 

FREE  THIS  CO  AFTER  THE  PENETRATQR 

N_NE&t_F_RE9=N_NEW_F_RE0+l 
NEW_MQDEL_REqFn_NEM ~F_RE9) =PROSECUTE_HODEL 
nem’f.req'i  N.NEN*  F.REQ)  =PRIMITI  ve_hodel 
NEH_SUB_F_REQ (N~NEW_F_RE9) =FREE_ONE_CO_AFTER_PEN_MODEL 
T_NEM_F~REQ (M_NEM_F~RE3 )=TMEXT  ' 

LOAD  THE  QUEUE  FOR  BASE  RETURNS 

N_NEH_F_REQ=M_NEH_F  REQ>1 
NEW.M  ^EL.P.EQIN.NEw’f  REQ)=NETWQRK_MQDEL 
NEW  F.RE3(N.NEw'f.REQ)=LDAD  3UEUE  MODEL 
NEW  SUB  F  REQM  NEW  F  REQ)=0 
T_NEW_F_RE9 (N_NEW_F_REQ>  =TNEXT 

DISENGA6E  UNIT  FOR  MISSES 

ELSE  IFISTATUS.EQ.MISS.STATUS)  THEN 

FREE  THIS  CO  AFTER  THE  PENETRATOR 

N.NEW.F.REQ-N.NEB.F.fiEflM 
NEW.M0DEL.RE3  c"n_HEwJf_REQ  I  s?ROSEOJTE_MQDEL 
NEW.F.REO^N.NEw'f.REQ)  PRIMITIVE  MODEL 
NEW~SUB_F_RE9 (N~NEW_F_RE3)  =FREE_ONE_CO_AF'i’ER  PEN  MODEL 
T_NEW_F~RE9 ( N_NEW_F*REQ ) *TNEXT  ' 

HANDOVER  CCR  ESCAPES 

N_NEW.F_RE9*NJEW_F_RE9+! 
NEW_m6dEL_RE3(N_NEW_F_REQ)=NETWQRK  MODEL 
NEw’f.REsIn.NEw'f.REQ) =LOAD.QUEUE  MODEL 
NEW .SUB  F  REQ'N  NEW_F_RE0)=0 
T_MEJW_F~RES  ( N_NEW_F*  RE3)  =TNEXT 

SEQUENCE  THE  LONS  FIRE  MODEL 

ELSE  I F ! STATUS. FO . LONGEST ATUS )  THEN 
N.NEW_F_P.E3=N_NEW,F_RE3+l 
NEW  MODEL  RE3!N  NEW  F  REO) =PROSECUTE  MODEL 


vi-s.vsv":-':-.- 


NEN.F.REQ  (N.NEN.F.REQ)  =C0_EN6_N0DEL 
NEW_SUB_F_REQ ( M~ NEM_F_REQ) =LQNG_FIRE_MODEl 
T.NEN.f'rEQ 1N_NEN_F*REQ) =TNEXT 

FREE  SERVERS  AND  SEQUENCE  THE  SHORT  FIRE  MODEL 

ELSE  IF (STATUS. EQ.SHQRT.STATUS)  THEN 

SEQUENCE  THE  SHORT  FIRE  MODEL 

N  NEN.F  REQ=N_NEM_F_REQ-H 
NEW.N0DEL.RE9 (N.NEW.F.REQ) -PROSECUTE.MODEL 
nek  f.reqIn  NEJI_F_REQ)  =PRIMITIVE_1DDEL 
NEW  SUB  F  REQ(N  NEW_F_REQ)=FREE_SERVER_MODEL 
T.NEH.f’rEQ !N_NEW_F_REQ) =tnext 

SHORT  FIRE  MODEL 

N  NEW_F_REQ=N_NEN_F_REQ+1 
NEH_MODEL_REQfN_NEM_F_REQ) =PROSECUTE_MODEL 
NEM*F_RE9-(N.NE/f.REqI*C0.EN6.M0DEL 
new.sub.f.reqin'nen.f  REQ^SHORT.FIRE.HODEL 
T_NEK_F~REQ (N_NEM_F_REQ) =TNEX T 

CANCEL  ALL  MISSIONS  AFTER  THIS  PENETRATOR 

ELSE  IF (STATUS. EG. DEAD.STATUS)  THEN 

FREE.CO_AFTER.PEN  HILL  DISEN6A6E  ALL  UNITS  IN  ALL  CO’S  AFTER  PEN 

N_NEW_F_REQ=N_NEW_F_REQ+1 

NEW.MQDEL.RE9 (N.NEW.F.REQ) =PROSECUTE.MQDEL 

NEH.F.REQ (N.NEH.F.REQ] =PRI MI TI VE.MODEL 

NEWJUB  F  RES(N~NEW_F.REQ)=FREE_CO.AFTER_PEN.NODEL 

T_NEM_F~REQ (N.NEH.F.REQ) =TNEXT 

NOTIFY  THE  NETWORK  OF  PENETRATOR  TERMINATION 

N_MEW_F.REQ=N_NEW_F_REQ+1 
NEW  MODEL  REQtN_NEN_F.REQ)=NETW0RK_!10DEL 
NEW'f.FEQ ( N.NEH*F.REQ) *TERN_PEN .MODEL 
NEW  SUB  F  REQ(N~NEW_F.REQ!=0 
T.NEW.f'f.EQ  (N.NEH.f'rEQ)  =TNEXT 

COLLECT  DESTRUCTION  STATISTICS 

N.NEH.F.REQ=N.NEW.F_RE9+! 
NEH.M0DEL_RE3!N.NEH.F.REQ)*STATISTICS.ENTRY.M0DEL 
NEH^F.REQ'N.NEH^.REQi^TERM.STATS.MODEL 
NEW  SUB  F  REQ (N.NEW.F.REQ) =0 
T  NEW  f’rEQIN  NEW  f"pEQ> =TNEXT 


E 


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 


C  CO.MATCH  IS  CALLED  FROM  THE  CO  INPUT  STATISTICS  EVENT  NODE  TD  ) 

C  DETERMINE  WHETHER  AN  INCOMING  MESSAGE  CAN  BE  PROCESSED.  THIS  t 

C  REQUIRES  THAT  BOTH  A  DETECTION  AND  AN  ASSIGNMENT  BE  LOCATED  AT  J 

:  THIS  NODE,  WITH  DATABASE  NUMBERS  THAT  HAVE  BEEN  RESOLVED  TO  * 

C  CORRESPOND  TO  THE  SAME  PENETRATOR,  AND  THAT  THE  CORRESPONDING  ! 

C  PENETRATOR  HAS  NOT  YET  LEFT  THE  CO’S  COVERAGE  REGION.  SINCE  : 

C  THERE  ARE  OTHER  SORTS  OF  MESSAGES  COMING  INTO  CO  THAT  DO  NOT  j 

C  REQUIRE  MERGER.  THIS  ROUTINE  MUST  CHECK  IF  THE  INCOMING  MESSAGE 

C  IS  AN  ENGAGEMENT  TYPE  OF  MESSAGE,  OR  ONE  OF  THE  OTHER  TYPES--  J 

C  REQUEST  FOR  SERVICE  FROM  A  MINI-CO,  OR  A  RESOURCE  ALLOCATION  ' 

C  COMMAND.  ( 

:  i 

C  ALPHATECH,  INC.  | 

P  * 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 
SUBROUTINE  CO.MATCH 

IMPLICIT  NONE  | 

ClimCOMHQN  BLOCKS  AND  PARAMETERS 
INCLUDE  ' DCO: SLAMPARAM. DIM’ 

INCLUDE  ’DCO:SCOMl.SLM’  , 

INCLUDE  ’DCO: PARAMETER. DIM’  I 

INCLUDE  ’ DCO: EXECUTIVE. DIM’ 

w 

C  «f (COMMON  BLOCK  ADDED  FOR  IDENTIFICATION  FEATURE*** 

n 

INCLUDE  ’ DCO: PENIDENT. INC’ 

C»*»**EXTERNAL  FUNCTIONS 
INTEGER  SET.AHAIT.FILE 

C  RETURNS'SLAH  INDEX  FOR  THE  PARTICULAR  AWAIT  FILE  NEEDED 

REAL  EXITJIME 

C  RETURNS  DEPARTURE  TIME  FROM  A  GIVEN  NODE-RETURNS  0  IF 

I  THE  PENETRATOR  HAS  ALREADY  LEFT  THE  REGION.  WHICH  IS 

C  WHAT  IS  TESTED  FOR  HERE 

3  LOGICAL  TRACE.ON 

C  RETURNS  TRUE  IFF  THE  SLAM  TRACE  FACILITY  IS  ENABLED 

C**»**LOCAL  VARIABLES 

INTEGER  ASSIBN.FILE,  DETECT.FILE 

O  TEMPORARY  VARIABLES  TO  STORE  SLAM  QUEUE  NUMBERS  FOR  THE 

C  TWO  FILES  IN  WHICH  MESSAGES  WAIT  TO  BE  MATCHED 

LOGICAL  TEMP.ALERT,  TEMP.DETECT 

C  TEMPORARY  VARIABLES  THAT  STORE  THE  STATE  OF  ALERT  AND 

C  DETECTION  IN  THE  MESSAGE  STORED  IN  ARRAY  ATRIB  iSCOMI) 


REAL  TEMP.ATRI8  (NUH.ATTRIEUTES) 

:  STORES  MESSAGES  RETURNED  FROM  SEARCH  AWAIT  FILE  UNTIL 

C  INFORMATION  FROM  THEM  MAY  BE  PROCESSED 

REAL  RADAR .DETECTED 

C  TEMPORARY  USED  IN  TRANSFERRING  INFORMATION  FROM 

C  TEMP  ATRIB  TO  ATRIB  (OR  VICE  VERSA) 

INTEGER  I 

C  LOOP  COUNTER 

INTEGER  CLASS,  ITEM 

C  LOCATION  OF  CURRENT  SYSTEM  CLASS;  DERIVED  FROM  ATRIB  ARRAY 

INTEGER  PEN 

C  PENETRATOR  TAIL  NUMBER:  ALSO  OBTAINED  FROM  ATRIB 

INTEEER  MESSASE.TYPE 

C  STORES  INCOMING  MESSAGE  TYPE 

LOGICAL  JUNK  BOOLEAN 
REAL  JUNK.ATRIB  (NUM.ATTRIBUTES) 

C  PARAMETERS  TO  CLEAR.FILE;  NOT  USED  HERE 

C 

CmttEXECUTABLE  CODE 

C  LOCAL  VARIABLES  DERIVED  FROM  THE  CONTENTS  OF  THE  MESSAGE 

CLASS  =  NINT  (ATRIB  (CURRENT  CLASS)) 

ITEM  =  NINT  (ATRIB  (CURRENT  ITEM)) 

PEN  =  NINT  (ATRIB  (TRUE  PEN  NO)) 

1ES3A5E  TYPE  *  NINT  (ATRIB  (CO  HESSA6E  TYPE)) 

TEMP.ALERT  =  (ATRIB  (ALERT.STATUS)  .E9.  TRUE) 

TEMP.DETECT  =  (ATRIB  (CO.DETECTIQN  RPT)  .ED.  TRUE) 

ASSIGN.FILE  =  GET.ANAIT.FILE  (CLASS,  ITEM,  ASSI6N.CCDE! 

DETECT.FILE  =  GET_AWAIT~FILE  (CLASS,  ITEM.  DETECT.CQDE) 
RADAR.DETECTED  =  ATRIB  "(RADAR.NUMBER) 

IF  (ATRIB  (HANDOVER .MESSAGE)  .Efl.  TRUE)  THEN 
WRITE  (ERROR. FILE,  *)  ’ERROR  IN  CO.MATCH’ 

WRITE  (ERRCR.FILE,  I) ’MESSAGE  RECEIVED  WITH  HANDOVER  =  TRUE’ 

CALL  UERR  (FATAL) 

C  IF  THIS  IS  AN  ENGAGEMENT  MESSAGE,  TAKE  ACTION  BASED  ON  THE 
C  VALUES  OF  ALERT  AND  DETECT 


ELSEIF  'MESSAGE.TYPE  ,E3.  CO.ENG.MODEl)  THEN 

IF  ((.NOT.  TEMP.ALERT!  .AND.*!. NOT.  TEMP.DETECT))  THEN 
WRITE  (ERROR.FILE,  t)  ’ERROR  IN  CO*MATCH: 

1  MESSAGE  RECEIVED’ 

WRITE  (ERROR.FILE,  I)  ’WITH  NEITHER  ALERT  OR  DETECT  ’, 

2  ’STATUS’ 

CALL  UERR  (FATAL) 

ELSEIF  (TEMP.ALERT  .AND.  (.NOT.  TEMP.DETECT?)  THEN 
IF  ! TRACE. 3N  (!)  THEN 

WRITE  (TRACEFILE,  *!  ’CCHATCH  SEARCHING  FOR  ’. 

1  ’DETECTION  REPORT’ 

WRITE  (TRACEFILE.  1)  ’C!LE  =  ’,  DETECT.FILE 


END  IF 

IF  (EXIT.TIME  (PEN,  CLASS.  ITEM)  .S3.  0.0)  THEN 
CALL  SEND_HAND0VER_MESSA6E  (CLASS,  ITEM,  ATRIB) 

II  =  DISCARD.CODE 
ELSE 

II  =  ASSI6N.C0DE 

CALL  SEARCH_AWAIT_FILE  (DETECT.FILE,  II, 

[  ATRIB,  TEMP.ATRIB) 

IF  (II  .£3.  NATCH  CODE)  THEN 

ATRI9  (RADAR  NUMBER)  =  TEMP  ATRIB  (RADAR.NUMBER) 

END  IF 
ENDIF 

ELSEIF  '(.NOT.  tEM?_AL£RT)  .AND.  TEMP.2ETECT)  THEN 
IF  (TRACE.ON  (!)  THEN 

WRITE  (TRACEFILE,  I)  ’COHATCH  SEARCHIN6  FOR 
[  ’ASSIGNMENT  REPORT’ 

WRITE  (TRACEFILE,  I)  ’FILE  =  ’,  ASSIGN.FILE 
ENDIF 

IF  ( EX  I T_TI ME  (PEN,  CLASS,  ITEM)  .EQ.  0.0!  THEN 
I!  =*DISCARD  CODE 

ELSE 

II  =  OETECT.CODE 

CALL  SEARCH_AWAIT_FILE  (ASSISN.FILE,  II, 

1  ATRIB,  TEMP  ATRIB) 

TEMF.ATRIS  RETURNS  THE  ASSIGNMENT  MESSAGE— IF  A  MATCH  HAS  BEEN 
FOUND,  THEN  THAT  MESSAGE  AND  NOT  THE  DETECTION  MESSAGE  SHOULD  BE 
KEPT. 

IF  (I!  .EQ.  MATCH.CODE!  THEN 
DO  I  =  I.  NUHATRI B_USED 
ATRIB  !!)*=  TEMMTRIB  (I! 

ENDDQ 

ATRIB  ( RADARNUMBER)  =  RADAR_DETECTED 
ELSEIF  (I!  .EQ.  DETECT.CODE!  THEN 

IF  NO  ASSIGNMENT  MATCH  WAS  FOUND,  THEN  CLEAR  ALL  PREVIOUS 
DETECTION  MESSA5ES  ABOUT  THIS  PENETRATOR  FROM  THIS  RADAR  QUT  OF 
THE  DETECTION  QUEUE  AT  THIS  POINT.  AND  REPLACE  THEM  WITH  THIS 
MESSAGE.  THE  MOTIVATION  FOR  THIS  IS  THE  FOLLOWING: 

IT  HAD  BEEN  IMPLEMENTED  PREVIOUSLY  THAT  EACH  RADAR  CAUSED 
ONLY  ONE  SIGHTING  MESSAGE  TO  BE  SENT  TO  ITS  COMMANDING  CO.  UNDER 
THE  ASSUMPTION  THAT  THAT  MESSAGE  WGULD  SUFFICE  TO  PRODUCE  ANY 
REASONABLE  ASSIGNMENTS.  THIS  NEGLECTED,  HOWEVER,  THE  DYNAMIC 
NATURE  OF  THE  DATABASE  IN  THE  SYSTEM.  IN  PARTICULAR,  UNDER  THE 
OLD  SCHEME,  IT  COULD  HAPPEN  THAT  A  SIGHTING  REPORT  AND  A 
DETECTION  REPORT  ON  A  PENETRATOR  WERE  SENT  TO  THE  SAME  CO  WITH 
DIFFERENT  DATABASE  NUMBERS,  SINCE  THE  ORIGINAL  MESSAGES  WERE 
GENERATED  AT  A  TIME  WHERE  THE  C3  SYSTEM  HAD  NOT  YET  DETERMINED 
THAT  THE  TWO  PUTATIVE  PENETRAT3RS  WERE  IN  FACT  ONE  AND  THE  SAME. 

IF  THE  MERGER  OCCURRED  WHEN  THESE  TWO  MESSAGES  WERE  ALREADY  AT 
THE  CO,  THOSE  MESSAGES  COULD  NOT  BE  RECONSIDERED.  THIS  LED  TO 
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THE  NEED  TO  CONTINUE  TO  SEND  MESSA6ES  TO  THE  CO  FROM  THE  SANE 
RADAR  ON  A  REGULAR  BASIS.  FOR  THE  NEW  SIGHTING  HESSASE  COULD  BE 
USED  TO  EFFECT  A  PROSECUTION  IF  IT  TRANSPIRED  THAT  MERGER  OF 
DATABASE  INFORMATION  HAS  OCCURRED  IN  THE  INTERVAL  BETWEEN  THE 
ARRIVAL  OF  THE  LAST  REPORT  AND  THE  ARRIVAL  OF  THE  CURRENT  REPORT. 

LEAVING  ALL  THESE  MESSAGES  AROUND,  THOUGH.  WOULD  LEAD  TO  A  VERY 
SUBSTANTIAL  SOFTWARE  LOAD  THAT  IS  IRRELEVANT  TO  MODEL  EXECUTION. 

FOR  ONLY  THE  LATEST  SIGHTING  REPORT  IS  RELEVANT.  HENCE  THESE 
MESSAGES  ARE  PURGED  HERE  BEFORE  THE  NEW  MESSAGE  IS  FILED  IN  THE 
FILE. 

AS  MENTIONED  ABOVE,  THIS  REPAIR  OCCURS  AT  A  LATE  DATE  IN  THE 
DEVELOPMENT  OF  TADZ  I.  PROBABLY  THE  CLEANEST  METHOD  OF  MODIFYING 
THIS  WOULD  SE  TO  REVAMP  THE  MESSAGE  ROUTING  IMPOSED  BY  THE  TESTS 
DONE  AT  CO  ON  THE  II  VARIABLE,  WHICH  CURRENTLY  CONTROLS  THE 
ROUTING  TO  THE  APPROPRIATE  QUEUE  OF  THE  MESSAGE  LEAVIN6  THIS 
NODE.  BUT  THAT  WOULD  REQUIRE  A  LOT  OF  CODE  CHANGES.  WHAT  WILL  BE 
DONE  INSTEAD  IS  TO  SIMPLY  REMOVE  ALL  MESSAGES  FROM  THE  DETECTION 
QUEUE  AT  THIS  POINT,  AND  LET  THE  REFILING  OF  THE  NEW  MESSAGE  BE 
TAKEN  CARE  OF  VIA  THE  OLD  MECHANISM  USING  THE  II  VARIABLE. 

JUNK  BOOLEAN  =  .TRUE. 

DOWHILE  (JUNK  BOOLEAN) 

CALL  CLEAR.ONE.DETECTION 

I  (DETECT.FILE,  PEN,  NINT (RADAR  DETECTED) 

l  ju'nk.boqlean,  JUNK.ATRIB) 

CLEAR  ONE.OETECTION  FINDS  ANY  DETECTION  OF  THAT  PENETRATOR  BY 
THAT  RADAR  THAT  IS  STORED  IN  THAT  FILE.  RETURNING  TRUE  IN  THE 
FOURTH  ARGUMENT  AND  ITS  ATTRIBUTES  IN  THE  FIFTH  ARGUMENT  IF  ONE 
IS  ACTUALLY  FOUND. 

ENDDO 

ENDIF 


IF  A  MATCH  WAS  FOUND.  CLEAR  OUT  ANY  REMAINING  ASSIGNMENT 
MESSAGES  THAT  NAY  BE  FOUND  IN  THE  ASSIGNMENT  FILE. 

IF  (II  ,E3.  MATCH,CCDE)  THEN 

CALL  CLEAR.F'lLE  (ASSIGN.FILE,  PEN.  JL'NKJQQLEAN, 

JUNK.ATRIB! 

ENDIF 

ENDIF 

THE  RESULT  OF  THE  TWO  PREVIOUS  CASES  IS  THE  SAME.  IF  A  MATCH  HAS 
BEEN  FOUND.  THE  ASSIGNMENT  REPORT  IS  TO  BE  FOUND  IN  THE  ARRAY 
ATRIB,  AND  THE  RADAR  INFORMATION  IN  T«AT  MESSAGE  IS  THE  RADAR 
DATA  FROM  THE  DEMOTION  REPORT. 


C  SUFFICIENT  TO  ALLOW  ACTION;  STILL  THE  AWAIT  FILES  MUST  BE 
C  CLEARED  OF  ANY  OTHER  MESSAGES  REGARDING  THIS  PENETRATOR 


1 


i 


IF  (EXIT.TIHE  (PEN,  CLASS,  ITEM)  . EQ-  O.O)  THEN 
ii  = ’discard  CODE 

CALL  SEND.HAND0VER.MESSA6E  (CLASS,  ITEM,  ATRIB) 
ELSE 


II  =  MATCH  CODE 

CALL  SEARCH  AWAIT  FILE  (ASSIGN  FILE,  II, 

ATRIB,  TEMP.ATRIB) 

CALL  SEARCH.AWAIT.FILE  (DETECT.FILE,  II, 

ATRIB,  TEMP.ATRIB) 


END  IF 


END  IF 
ENDIF 


C  AN  ENGAGEMENT  MESoAGE  WILL  BE  PROCESSED  FURTHER  FROM  THIS  NODE 
C  IFC  I!  =  MATCH  CODE;  IN  THIS  CASE  (AND  WHEN  THE  MESSAGE  IS  OF 

C  CNE  OF  THE  OTHER  TYPES)  IT  MUST  BE  CALCULATED  IN  WHAT  QUEUE 

0  THIS  MESSAGE  IS  TO  AWAIT  PROCESSING.  NOTE  THAT  CO  NODES  USE 

C  SLAM  AWAIT  NODES  INSTEAD  CF  QUEUES  TO  WAIT  FOR  SERVICE. 

0  NONETHELESS,  DETERMINE JUEUE  IS  STILL  USABLE  TO  FIND  THE  SLAM 

C  FILE  NUMBER,  SINCE  CO  FILES  HAVE  THE  SAME  LAYOUT  AS  OTHER 

0  FILES.  TQ  A  SUFFICIENT  LEVEL  OF  DETAIL 
C 

C  NOW  MAKE  SURE  THAT  ALL  NON-ENGAGEMENT  MESSAGES  AND  THE  ENGAGEMENT 

0  MESSAGES  WHICH  HAVE  FOUND  MATCHES  (AND  HENCE  NEED  NOT  WAIT  IN 

C  ONE  OF  THE  AWAIT  QUEUES)  CAN  BRANCH  TO  THE  SELECT  NODE  FOR 

0  ASSIGNMENT  TO  ONE  OF  THE  MAIN  CO  QUEUES. 

C 


C  Ut  CODE  CHANGE  ADDED  TO  DISCARD  ENGAGEMENT  MESSAGES  III 
C  Ut  tHAT  HAVE  II  =  MATCH.CODE  (BE6IN  PROSECUTION).  IN 
C  Ut  THOSE  CASES  WHERE  THE  ID  CODE  PREVENTS  EXECUTION. 

C  Ut  (ID  INDEX  =  5, 6, 7, 3),  THE  ROUTINE  MUST  SET 

C  U»  II  =~DI5CARD  CODE  SO  THE  MESSAGE  WILL  BE  DISCARDED 


IF  IREN .IDENT (PEN)  ,LT.  5)  THEN 

C  Ut  CONTINUE  ORIGINAL  COMATCH  CODE 
C  Ut  IF  ID  IS  HOSTILE  '3.4) 

r 

L 

IF  (PEN.IDENT(PEN)  .ST.  2)  THEN 
IF  (MESSAGE.TYPE  ,NE.  CO.ENG.MODEL)  THEN 
II  =  MATCH.CODE 
ENDIF 


IF  (II  .£3.  MATCH.CODE)  THEN 
CALL  DETERMINE jiUEUE 

IF  t MESSAGE.TYPE  .EQ.  CO.ENG.MODEL)  THEN 
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ATRIB  (CO.DETECTIQN.RPT)  =  TRUE 
ATRIB  (ALERT  STATUS)  =  TRUE 

ENDIF 

ENDIF 

m  IF  ID. INDEX  IS  UNKNOWN  (1  OR  2)  THEN  ALLOW 

ttt  PROSECUTION  ONLY  IF  A  FISHTER  CO  (ITEM  LESS  THAN  4) 

»»  ITEM  IS  THE  INDEX  FOR  THE  ORDER  OF  CO’S 

ELSEIF  (PEN.IDENT(PEN)  .LT.  3)  THEN 


IF  ID  CODE  WAS  ONE  OR  TWO  AND  THE  CO  IS  A 
FIGHTER  THEN  CONTINUE  WITH  ORIGINAL  CODE 

IF  (ITEM  , LT.  4!  THEN 

IF  (HESSAGE.TYPE  .NE.  CO.ENS.MQDEL!  THEN 
II  =  MATCH .CODE 
ENDIF 

IF  (II  .EQ.  MATCH.CODE!  THEN 
CALL  DETERMINE ‘QUEUE 

IF  (MESSAGE.TYPE  . EO.  C0.EN6.M0DEL)  THEN 
ATRIB  (CO  DETECTION  RPT)  =  TRUE 
ATRIB  (ALERT  STATUS)  =  TRUE 

ENDIF 

ENDIF 

ENDIF 

ENDIF 


II  =  DISCARD  CODE 


CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 


w 

C  THIS  FILE  CONTAINS  USERF  AND  SERVICE.TIHE,  WHICH  SERVE  TO  RETURN 

:  THE  SERVICE  TIME  FOR  ACTIONS  AT  ANY  STANDARD  SERVICE  NODE. 

C 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 

C  USERF  IS  A  STANDARD  SLAM  FUNCTION,  USED  FOR  CALCULATINS  DURATIONS 

C  OF  ACTIVITIES  AND  ASSIGNING  ATTRIBUTES  IN  ASSIGN  NODES.  AT  THIS 

C  POINT,  ONLY  THE  FORMER  USAGE  OCCURS  IN  TADZ.  USERF  (1)  IS  CALLED 
C  TO  DETERMINE  THE  SERVICE  TIME  IN  A  SYSTEM  NODE.  THIS  IS  ACTUALLY 

C  DONE  IN  FUNCTION  SERVICE.TIHE,  CALLED  FROM  HERE.  AS  IN  SUBROUTINE 

C  EVENT.  ICODE  IS  A  SELECTOR  VARIABLE.  AND  ALL  VARIABLES  AND  VALUES 

C  USED  IN  THE  CALCULATIONS  ARE  PASSED  IN  COMMON  BLOCKS. 

n 

L 

C  ALPHATECH.  INC. 
r 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 
REAL  FUNCTION  USERF  (ICODE) 

n 

i 

IMPLICIT  NONE 

CmilINP'JT  VARIABLES 
C 

INTEGER  ICODE 

C  INPUT  CASE  SELECTOR 

C 

CmmCOMMON  BLOCKS  AND  PARAMETERS 
INCLUDE  ’ DCC : PARAMETER. DIM’ 

i 

CmillLCCAL  VARIABLES 
REAL  RETURN.TIME 

C  RETURNS  VALUE  OF  SERVICE  TIME  AT  A  GIVEN  SYSTEM  NODE 

CmmEXECUTABLE  CODE 

IF  ( ICODE. ED. SEP.V_T IHE.CDDE)  THEN 
CALL  SERVICE.TIME  (RETURN.TIME) 

USERF  =  RETURN. TIME 

ELSE 

WRITE  (ERROR.FILE,  »)  ’ERROR  IN  USERF’ 

WRITE  (ERROR*FILE.  *!  ’UNKNOWN  FUNCTION  CODE  =  ICODE 
CALL  OERR  (FATAL) 

ENDIF 


RETURN 

END 


A-3 1 


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 

c 

C  '  SERVICE, TIME  (INPUT  PARAMETERS  PASSED  IMPLICITLY  IN  THE 
C  COMMON  BLOCK  SCQM.8LK,  BECAUSE  OF  THE  CONSTRAINTS 
C  IMPOSED  BY  SLAM)  RETURNS  TO  THE  GENERIC  SYSTEM  NODE  THE  SERVICE 
C  TIME  AS  A  FUNCTION  OF  THE  NUMBER  OF  REPORTS  FUSED  TO  PRODUCE 

C  THE  OUTPUT  REPORT.  IT  INVOLVES  MULTIPLE  CALLS  TO  THE  SLAM 

C  ROUTINES  NFIND  (FOR  SEARCHING  FILES  TO  FIND  ENTITIES  WITH 

C  MATCHING  ATTRIBUTES)  AND  COPY  (TO  OBTAIN  THE  ATTRIBUTES  OF  THESE 

C  ENTITIES).  REPORTS  ON  THE  ENTRIES  DETERMINED  BY  SERVICE.TIME  TO 

C  BE  EXTRA  INFORMATION  ARE  LOADED  INTO  THE  COMMON  BLOCK 
C  REMOVAL.RECORDS  FOR  EVENTUAL  DISCARDING  IN  REMOVE.DUPLICATE  MESSAGES 
C  IT  DOES  NOT  WORK  TO  TRY  TO  REMOVE  THOSE  RECORDS  FROM  THE  QUEUES 

C  IN  THE  COURSE  OF  THIS  ROUTINE. 

C 

C  THIS  SUBROUTINE  SHOULD  BE  CALLED  ONLY  FROM  THE  SLAM  FUNCTION 

C  USERF. 

C 

C  ALPHATECH,  INC. 

f* 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 

SUBROUTINE  SERVICE  TIME  (RETURN  TIME) 

IMPLICIT  NONE 

CmuOUTPUT  PARAMETERS 

r 

REAL  RETURN  TIME 

C  SERVICE  TIME  RETURNED  TO  USERF 

C 

CmmCOMMCN  BLOCKS  AND  PARAMETERS 
•« 

INCLUDE  ’OCO:SLAMPARAM.DIM’ 

INCLUDE  ' DCO: SCOW 1. SLIT 
INCLUDE  ’DCOiPARAMETER.DIH’ 

INCLUDE  'DCO: REMOVAL. INC’ 

INCLUDE  ’DCO:SOINIT.PRH’ 

INCLUDE  ’DC0:S1INIT.PRM’ 

INCLUDE  ’ DCO: S2INIT. PPM’ 

INCLUDE  ’DC0:C2INIT.PRM’ 

INCLUDE  ’DCOiClINIT.PRM’ 

INCLUDE  ' DCO: COINIT. PPM’ 

INCLUDE  ’ DCO: SYSCCM. INC’ 

C 

tmmEXTERNAL  FUNCTIONS 
INTEGER  NFIND 

C  USED  TO  RETURN  RANK  IN  A  FILE  OF  AN  ENTRY  WITH  GIVEN 

0  ATTRIBUTES 

INTEGER  NN9 


A -37 


c 


ELAN  FUNCTION  RETURNS  NUMBER  OF  ENTRIES  IN  A  QUEUE 


cmm  ADDED  FOR  EXPONENTIAL  SERVICETIMES 
REAL  EXPON 

C  SLAM  FUNCTION  RETURNS  A  SAMPLE  FROM  AN  EXPONENTIAL 

Z  DISTRIBUTION  WITH  SPECIFIED  MEAN 

cmttmtmmtmmmmmmtmt 

REAL  UNFRM 

C  SLAM  FUNCTION  RETURNS  A  SAMPLE  FROM  A  UNIFORM 

C  DISTRIBUTION  WITH  SPECIFIED  ENDPOINTS.  USIN6  GIVEN 

C  RANDOM  NUMBER  STREAM. 

D  LOGICAL  TRACE.ON 

C  TRUE  IFF  THE  SLAM  TRACE  FACILITY  IS  CURRENTLY  ENABLED 

CHARACTERI2  CLASS.STRING 

C  CONVERTS  INTEGER  CLASS  REPRESENTATION  INTO  A  STRING 

REAL  CURR.TIHE 

C  OBTAINS  THE  CURRENT  TIME 

CltHIILDCAL  VARIABLES 

REAL  TEMP  ATRIB  (NUM.ATTRIBUTES) 

C  ARRAY  FOR  TEMPORARY  STORAGE  OF  ATTRIBUTES  IN  ENTITIES 

C  BEING  REMOVED  FROM  THE  QUEUES 

INTEGER  MESSAGE.COUNT 

C  NUMBER  OF  MESSAGES  BEING  PROCESSED  BY  THIS  SYSTEM 

C  NODE  IN  THE  COURSE  OF  THIS  CALL 

INTE5ER  FILES  (MAX  FILES  TO  CHECK),  CURRFILE 
C  TEMPORARIES  TO  STORE  THE  INDICES  OF  SLAM  QUEUES  FOR 

C  USE  IN  SEARCHING  FOR  DUPLICATE  MESSAGES 

.OGICAL  MESSAGE_FQL'ND_IN_9UEUE  (MAX.FILES.TO.CHECK) 

C  FLAGS  TO  INDICATE  WHETHER  MATCHED  MESSAGE  WAS  FOUND  IN 

C  THE  FILES  NAMED  IN  ARRAY  FILES. 

INTEGER  RANK 

C  TEMPORARY  VARIABLES  USED  IN  REMOVING  MESSAGES  FROM  QUEUES 

C  RANK  POINTS  TO  A  MESSAGE  WITH  MATCHING  ATTRIBUTES 

C  (==  CORRESPONDING  TO  THE  SAME  PENETRATOR) 

REAL  STORE.SYS.TARGET 

C  TEMP’jSED  TO  AVOID  OVERWRITING  C'JRR.SYS .TARGET 

REAL  STORE.ALERT.STATUS 

C  SIMILARLY  STORES  FIRST/CONTINUED  REPORT  STATUS  OF 

C  ORIGINAL  MESSAGE,  AS  MAINTAINED  IN  ATTRIBUTE  ALERT  STATUS 

REAL  STCRE.LAST.CLASS,  STORE J.ASTJTEM 
C  STORAGE  LOCATIONS  FOR  NAME  OF  LAST  SYSTEM  NODE  THAT  THIS 

C  MESSAGE  PASSES  THROL'SH.  THIS  MUST  BE  PROPERLY  SAVED  SO 

C  THAT  THE  ALLOCATION  TABLE  UPDATING  ROUTINE  CAN  PROPERLY 

C  DETERMINE  IF  THE  CURRENT  MESSAGE  IS  THE  'CURRENT  SYSTEM 

C  MESSAGE’  ABOUT  THE  GIVEN  PENETRATOR.  AND  NOT  AN  ATTEMPT 

C  TO  PRODUCE  ANOTHER  FIRST  REPORT  (AND  HENCE  A  MULTIPLE 

C  ALLOCATION)  SOMEWHERE. 

REAL  STQRE.CO.DETECTICN.RPT 

C  SAVES  AND  ACCUMULATES  THE  VALUE  OF  CO  DETECTION  RPT .  IF 


C  ANY  OF  THE  MERGED  MESSAGES  ARE  MARKED  AS  HAVING  TRACK 

C  INFORMATION  SUFFICIENT  TO  CONDUCT  AN  ENGAGEMENT,  THEN 

C  THE  AGGREGATED  MESSAGE  SHOULD 

INTEGER  C.SIDE.CLASS,  C.SIDE.ITEM 

C  ALSO  POTENTIALLY  USED  IN  GENERATING  THE  APPROPRIATE 

0  ENTRIES  FOR  LAST  CLASS,  LAST  ITEM  IN  THE  OUTGOING  MESSAGE 

INTEGER  INT_LAST_CLASS 

C  NEAREST  INTEGER  TO  ATRIB  (LAST  CLASS);  USED  FOR  COMPARISONS 

INTEGER  I,  J 

C  COUNTERS 

INTEGER  PEN 

C  PENETRATOR  TAIL  NUMBER 

INTEGER  CLASS,  ITEM 

C  SYSTEM  NODE  AT  WHICH  SERVICE  IS  BEING  PERFORMED 

REAL  TEMP.CURR.TIME 

C  SAVES  THE  RETURNED  VALUE  OF  THE  CURRENT  TIME 

C 

C  THE  FOLLOWING  VARIABLES  ARE  USED  TO  STORE  THE  PARAMETERS  EXTRACTED 
C  FROM  THE  VARIOUS  NODE  INITIALIZATION  BLOCKS.  THESE  VALUES  ARE  USED 
C  IN  THE  FINAL  CALCULATION  OF  THE  SERVICE  TIME. 

C 

REAL  FIRST  TIME 

C  TIME  FOR  A  FIRST  REPORT  TO  BE  PROCESSED  AT  THE  GIVEN  NODE 

REAL  CONTINUED  TIME 

C  DITTO  FOR  A  CONTINUED  REPORT 

REAL  FUSION  TIME 

C  ADDITIONAL  TIME  REQUIRED  FOR  EACH  ADDITIONAL  MESSAGE  TO 

C  BE  FUSED  WITH  THE  PREVIOUSLY  FOUND  MESSAGES  REGARDING 

C  THE  SAME  PENETRATOR 

REAL  FIRST.MESSAGE.TIHE 

C  TIME  REQUIRED  TO  SERVICE  THE  FIRST  MESSAGE,  DEFENDING  ON 

C  WHETHER  IT  IS  A  FIRST  OR  A  CONTINUED  REPORT,  INCLUDING 

C  STOCHASTIC  EFFECTS 

REAL  F'JSION.SUM 

C  SUM  TOTAL  OF  TIME  REQUIRED  TO  PERFORM  FUSION  ON 

C  ADDITIONAL  MESSAGES  BEING  FUSED  WITH  ORIGINAL  MESSAGE— 

C  ALSO  STOCHASTIC 

REAL  MULTIPLIER 

C  IF  THE  NODE  PERFORMING  THE  SERVICE  IS  NOT  PERFORMING  ITS 

C  ORIGINAL  FUNCTION,  IT  CAN  BE  EXPECTED  TO  TAKE  LONGER  TO 

C  COMPLETE  SERVICE.  MULTIPLIER  IS  USED  TO  ADD  THAT  ADDITIONAL 

0  'ERM  TO  THE  EXPRESSION  'OR  SERVICE  TIME. 

C 

CIUIUEXECUTABLE  CODE 


ONE  SIDE  EFFECT  OF  TH!S  FUNCTION  IS  TO  POSSIBLY  RESET  THE  XX 
VARIABLE  ASSOCIATED  WITH  THIS  QUEUE  TO  TALLY  THE  BUSY  STATUS 
CF  THE  QUEUE  THIS  MESSAGE  WAS  JUST  TAKEN  FROM,  TO  CALCULATE 
THE  °RQBA5ILITY  OF  QUEUEING  FOR  A  MESSAGE  OF  THIS  TYPE 


IF  (UNO  ’MINT  (ATRIP  'MOST.RECENT.QUEUE) ! !  ,EQ.  0!  THEN 
U  (NINT  (ATRIB  (HOST  RECENT  QUEUE) ! )  =  0 
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THE  MESSAGE  COMING  OUT  OF  THIS  PROCESS  IS  THE  MESSAGE  OF 
HIGHEST  PRIORITY  FOUND  IN  THE  CURRENT  C3  NODE. 

THE  NUMBER  OF  MESSAGES  FUSED  TO  GENERATE  THIS  MESSAGE  IS 
A  FACTOR  IN  DETERMINING  THE  AGGREGATE  SERVICE  TIME. 

THE  MESSAGE,  HOWEVER,  MUST  INDICATE  THAT  THERE  IS  A  CURRENT 
SYSTEM  TARGET  IF  ANY  OF  THE  FUSED  MESSAGES  SAY  THERE  IS.  EVEN 
IF  THE  LATEST  MESSAGE  DOES  NOT  SAY  SO.  SINCE  ALL  MESSAGES 
REGARDING  SYSTEM  TARGETS  ARE  OF  THE  HIGHEST  PRIORITY,  IF  THE 
INPUT  MESSAGE  TO  THIS  NODE  (WITH  ATTRIBUTES  IN  ATRIB)  DOES  NOT 
STATE  THAT  THE  SYSTEM  IS  ENDANGERED.  THEN  NONE  OF  THE  MESSAGES 
REGARDING  THIS  PENETRATOR  WILL.  THIS  ATTRIBUTE  IS  STORED  IN 
ST0RE.3YS.TARGET,  TO  BE  RESTORED  TO  THE  FINAL  MESSAGE  UPON 
LEAVING  THIS  PROCESS.  SIMILARLY.  IF  THE  REPORT  BEING  SERVICED 
IS  NEITHER  AN  INDICATION  OF  IMPENDING  DANGER  TO  THE  SYSTEM  NOR 
A  FIRST  REPORT,  THEN  ALL  THE  OTHER  REPORTS  MERGED  WITH  IT  HERE 
WILL  ALSO  BE  CONTINUED  REPORTS. 

IT  IS  ALSO  NECESSARY  TO  SAVE  THE  LAST  CLASS  AND  ITEM  THAT  THIS 
MESSAGE  PASSED  THROUGH,  FOR  THOSE  VALUES  ARE  NEEDED  FOR  THE 
PROPER  HAINTAINENCE  OF  THE  ALLOCATION  TABLE,  AS  WILL  BE  SEEN 
BELOW. 

STORE.SYS.TARGET  =  ATRIB  (C'JRR  SYS  TARGET) 

STORE.ALERT.STATUS  =  ATRIB  (ALERT.STATUS) 

STORE.LAST.CLASS  =  ATRIB  (LAST.CLASS! 

STORE  LAST  ITEM  =  ATRIB  (LAST  ITEM) 

STQRE.CO.DETECTIQN  RPT  =  ATRIB  (CO.BETECTION  RPT) 

C.SIDE.CLASS  =  0 
C.SIDE.ITEN  =  0 

PEN  =  NINT  (ATRIB  tTRUE_PEN.NO)) 

CLASS  =  NINT  (ATRIB  (CURRENT.CLASS) ! 

ITEM  =  NINT  (ATRIB  (CURRENT JTEM) ! 

ME5SAGE.C0UNT  =  NINT  (ATRIB  (CURR.NUM.MESSAGES) ) 

DETERMINE  WHAT  FILES  MESSAGES  ABOUT  THIS  PENETRATOR  MAY  BE  IN 

CALL  5ET.FILES  (CLASS,  ITEM,  FILES,  ATRIB) 


DO  I  =  1 ,  MAX.FILES.TO.CHECK 

MESSAGE  FOUND.IN  QUEUE  (I)  =  .FALSE. 

ENDDO 

DO  I  =  ! ,  MAX.FILES.TO.CHECK 
CURRFILE  =  FILES  (I) 

CHECK  EACH  OF  THESE  FILES  FOR  FURTHER  MESSAGES  REGARDING  THIS 
PENETRATOR. 


IF  (CURRFILE  .NE.  0)  THEN 
RANK  =  1 

r* 

C  START  SEARCH INS  FROM  THE  FIRST  ENTRY 
C 

DOMHILE  ((RANK  .NE.  0)  .AND.  (RANK  .LE.  NNQ  (CURRFILE))) 
RANK  =  NFIND  (RANK,  CURRFILE,  TRUE_PEN_NO,  0, 

1  ATRIB  1tRUE.PEN.NQ),  0) 

C 

C  THESE  PARAMETERS  CAUSE  SLAM  TO  LOOK  FOR  AN  ENTRY  IN  FILE 
C  CURRFILE  WHOSE  ATTRIBUTE  TRUE.PEN.NQ  IS  AN  EXACT  HATCH  FOR  THE 

C  SAME  ATTRIBUTE  IN  THE  ARRAY  ATRIB,  I.E.  THE  MESSASE  REFERS  TO 

Z  THE  SAME  FENETRATOR.  THE  REMAINDER  OF  THIS  DO  LOOP  IS  EXECUTED 

C  ONLY  IF  SUCH  A  MATCH  WAS  FOUND. 

IF  (RANK  .NE.  0)  THEN 

MESSAGE.FOUND.IN.QUEUE  (I)  «  .TRUE. 

CALL  COPY  (RANK,  CURRFILE,  TEMP.ATRIB) 

MESSAGE  COUNT  =  HESSASE.COUNT  +  NINT  'TEMP.ATRIB 
1  (CURR.NUM.MESSAGES) ) 

C  SAVE  THE  LAST  SYSTEM  NODE  IF  THAT  NODE  WAS  A  C  SIDE  NODE. 


1 


r 


+ 


1 
C 

C  THE  REPORT  JUST  RETRIEVED  FFOM  THE  QUEUE  IS  MORE  RECENT  THAN 

C  THE  PREVIOUS  ONE.  REPLACE  THE  OLDER  REPORT  WITH  THE  NEWER  ONE 

DO  J  =  1,  NUM. ATP IB. USED 

ATRIB  (J)  =  TEMP.ATRIB  (J) 

ENDDO 

ENDIF 

C  GG  ON  T0  THE  NEXT  MESSAGE  IN  THE  FILE  FOR  THE  NEXT  TIME  THROL'SH 
THE  LOOP 


INT  LAST  CLASS  =  NINT  (TEMP  ATRIB  (LAST.CLASS) ) 

IF  ((INT  LAST  CLASS  .EQ.  C2)  .OR. 

(INT.LAST  CLASS  .EO.  Cl)  .OR. 

(INT  LAST  CLASS  .EQ.  CO!)  THEN 
C  SIDE  CLASS  =  INT  LAST  CLASS 
C.SIDE.ITEM  =  NINT  (TEMP.ATRIB  (LAST.ITEM) ) 
ENDIF 

IF  (TEMP.ATRIB  (CO.DETECTIOM.RPT)  .ES,  TRUE) 

THEN 

STORE.CO_DETECTION.RPT  =  TRUE 

ENDIF 

IF  (TEMP.ATRIB  (LAST.REPORT.TIME)  .ST. 

ATRIB  (LAST.REPORT.TIME))  THEN 


RANK  =  RANK  +  1 


m 


ENDDO 

NOW  CURRFILE  MAY  HAVE  BEEN  EMPTIED  OF  MESSAGES  IN  THE  PROCESS 
OF  PERFORMING  THIS  MERGER.  IF  SO.  THEN  RESET  THE  XX  VARIABLE 
WHICH  INDICATES  WHETHER  THERE  IS  A  MESSAGE  IN  CURRFILE.  (IT 
CAUSES  NO  HARM  TO  PERFORM  THIS  RESET  IF  THE  FILE  WAS  INDEED 
EMPTY  ALREADY.) 

IF  (NNQ  (CURRFILE)  .EQ.  0)  THEN 
XX  (CURRFILE)  =  0.0 
ENDIF 

END  IF 
ENDDO 

AT  THIS  POINT  MESSAGE.CQUNT  CONTAINS  A  COUNT  OF  THE  NUMBER  OF 
MESSAGES  FOUND  THAT  REFERRED  TO  THE  TARGET  CURRENTLY  UNDER 
CONSIDERATION.  THE  FILE(S)  IN  WHICH  ANY  DUPLICATE  MESSAGE  IS 
LOCATED  ARE  INDICATED  BY  .TRUE.  ENTRIES  IN  MESSAGE.FOUND  IN  QUEUE. 
THE  ATTRIBUTES  OF  THE  MOST  RECENT  MESSAGE  (WHICH  IS  NOT  ' 
NECESSARILY  THE  MESSAGE  THAT  WAS  ORIGINALLY  BEING  SERVED)  ARE 
LOCATED  IN  ARRAY  ATRIB,  AND  THE  VARIABLE  ST0RE.SYS.TAR6ET 
CONTAINS  A  VALUE  WHICH  INDICATES  WHETHER  ANY  OF  THE  MESSAGES 
INDICATED  THAT  A  SYSTEM  COMPONENT  WAS  IMMINENTLY  UNDER  ATTACK. 

NOW  CLEAN  UP  THESE  VALUES. 

DO  I  M,  MAX.FILES.TO.CHECK 

IF  (MESSA6E.F0UNDJNJUEUE  (I))  THEN 

INDICATE  IN  COMMON  BLOCK  PASSED  TO  REMOVAL  SYSTEM  NODE  THAT  THIS 
FILE  MUST  BE  SEARCHED  FOR  ELEMENTS  MATCHING  THE  PENETRATOR 
NUMBER.  IT  WOULD  INDEED  BE  MORE  NATURAL  TO  SIMPLY  DISCARD  ALL 
THE  DUPLICATED  MESSAGES  HERE,  BUT  DOING  SO  IN  THE  CONTEXT  OF  THE 
SLAM  FUNCTION  USERF  (WHERE  SERVTIME  IS  CALLED)  CAUSES  THE 
POINTER  MFA  (WHICH  LOCATES  THE  HEAD  OF  THE  FREE  MESSAGE  SLOT 
LIST  IN  THE  COMMON  ARRAY  NSET/GSET)  TO  BE  DISLOCATED,  AND  SLAM 
EITHER  DIES  FAIRLY  SHORTLY  THEREAFTER  OR  ELSE  YIELDS  TRUE 
NONSENSE  FOR  THE  NEXT  ACTIONS. 


NUM_FILE5_T0_SEARCH  =  NUM_FILES.TQ_SE.ARCH  +  1 
IF  (NUM.FILE5.T0. SEARCH  .GT.  MAX.FILES.TO.MATCH)  THEN 
WRITE  (ERPOR'fILE.  I)  ’ERROR  IN  SERVICE  TIME’ 

WRITE  (ERROR.FILE,  I)  ’OVERFLOW  OF  LIST’oF  FILES  ’, 

’MARKED  FOR  DELETION’ 

<>  ’FILES  NAMED  TO  BE  SEARCHED’ 
I)  (FILES. TO.SEARCH  ( J) .  J  =  1 , 
MAX’  FILES  TO  MATCH) 


WRITE  (ERROR.FILE, 
WRITE  (ERROR.FILE, 


CALL  L'ERR  (FATAL) 


ELSE 


FILES.TO. SEARCH  'NUM.rILES.TO.SEARCH!  =  FILES  (I) 
ATRIB.VALUE.TO.MATCH  ( NUM.F I LE5. TO. SEARCH )  = 

1  "  ATRIB  (TRUE.PEn’nO) 
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ATRIB  (CURR.SYS.TARGET)  =  STORE  SYS  TARGET 
ATRIB  IALERT.STATUS)  *  STORE. ALERT.STATUS 
IF  (ATRIB  (HANDOVERJ1ESSAGE)  .£0.  TRUE)  THEN 
ATRIB  (CO.DETECTION.RPT)  =  FALSE 

...  SINCE  A  HANDOVER  MESSAGE  IS  BEING  PASSED  UP  THE  CHAIN  OF 
COMMAND,  THE  TRACK  INFORMATION  THAT  HAY  BE  ASSOCIATED  NITH  THIS 
MESSAGE  CAN  NO  LONGER  BE  RELEVANT;  IT  HASN’T  POSSIBLE  TO  PERFORM 
PROSECUTION  IN  THE  IMMEDIATE  NEIGHBORHOOD 

ELSE 

ATRIB  (CO.DETECTION.RPT)  =  STORE  CO.DETECTION.RPT 
ENDIF 

NON  RESET  THE  LAST  CLASS  AND  LAST. ITEM  ATTRIBUTES,  SO  THAT  ANY 
MESSAGE  THAT  CAME  FROM  THE  C  SIDE  HAS  ITS  SOURCE  NODE  PRESERVED. 
THE  ORDERING  IS  CHOSEN  SO  THAT  IF  THE  ORIGINAL  MESSAGE  BEING 
PROCESSED  (I.E.  THE  MESSAGE  AT  THIS  NODE  OF  THE  HIGHEST 
PRIORITY)  CAME  FROM  THE  C  SIDE,  THEN  ITS  SOURCE  NODE  IS  THE 
SOURCE  NODE  OF  THE  ENSUING  MESSAGE.  OTHERNISE  IF  ANY  OTHER 
MESSAGE  CAME  FROM  THE  C  SIDE  THEN  USE  ITS  SOURCE  NODE,  AS  SAVED 
IN  C  SIDE  CLASS  AND  C.SIDE  ITEM.  IN  ANY  OTHER  CASE  IT  SUFFICES 
TO  USE  THE  MOST  RECENT  MESSAGE’S  LAST  CLASS/ ITEM. 

INT.LAST.CLASS  =  NINT  (STORE.LAST.CLASS) 

IF  ((INT.LAST.CLASS  .EQ.  C2>  .OR.  (INT.LAST.CLASS  .E9.  Cl) 
l  .OR.  (INT.LAST.CLASS  ,E3.  CO))  THEN 

ATRIB  (LAST.CLASS)  =  STQRE.LAST  CLASS 
ATRIB  (LAST.ITEM)  =  STORE.LASf  ITEM 
ELSEIF  (C.SIDE.CLASS  .NE.  0)  THEN 
ATRIB  (LAST.CLASS)  =  C.SIDE.CLASS 
ATRIB  (LAST.ITEM)  =  C.SIDE  JTEH 
ENDIF 

COLLECT  THE  APPROPRIATE  PARAMETERS  FOR  SERVICE  BASE  TIMES  FROM 
THE  VARIOUS  INITIALIZATION  COMMON  BLOCKS,  DEPENDING  ON  THE 
CLASS  OF  NODE  PERFORMING  THE  SERVICE.  ONLY  FOR  SC  AND  C2  NODES 
CAN  MULTIPLIER  TERMS  OTHER  THAN  1  APPLY. 

IF  (CLASS  .EQ.  SO)  THEN 

CIRST.TIME  =  FIRST.SO  SERVICE  'ITEM) 

CONTINUED. TIME  =  CCNT.SO.SERVICE  (ITEM) 

•"'JSION.TIME  =  FUSION  JO  SERVICE  (ITEM) 

MULTIPLIER  =1 
ELSEIF  (CLASS  .EQ,  SI)  THEN 

FIRST.TIME  =  FIRST. SI. SERVICE  (ITEM) 

CONTINLe.TIME  =  CON  7.  SI.  SERVICE  (ITEM) 

FUSION  tihe  =  FUSION  5!  SERVICE  (ITEM) 


*1ULTIPLIER  =  1 

ELSEIF  (CLASS  .EO.  SC)  THEN 

FIRST.TIME  =  FIRST.S2.SERVICE  (ITEM) 

CONTINUED.TIME  =  C0NT.S2.SERVICE  (ITEM) 

FUSION.TIME  *  FUSIQN.S2.SERVICE  (ITEM) 

IF  (ACTUAL.S2.CLASS  .EQ.  SI)  THEN 

MULTIPLIER  =  1  /  31  S2  MULTIPLIER  (ACTUAL  S2  ITEM) 

ELSE 

MULTIPLIER  =  1 

ENDIF 

ELSEIF  (CLASS  .EQ.  C2)  THEN 

FIRST.TIME  =  FIRST.C2.SERVICE  (ITEM) 

CCNTINUED.TIME  =  CCNT.C2.SERV1CE  (ITEM) 

FUSION.TIME  =  FUSI0N.C2.SERVICE  (ITEM) 

IF  (ACTUAL.C2.CLASS  .EQ.  Cl)  THEN 

MULTIPLIER  =  i  /  C2  C2  MULTIPLIER  (ACTUAL  C2  ITEM) 

ELSE 

MULTIPLIER  =  1 

ENDIF 

ELSEIF  (CLASS  .EQ.  Cl)  THEN 

FIRST.TIME  =  FIRST.Cl.SERVICE  (ITEM) 

CCNTINUED.TIME  =  CONT.Cl.SERVICE  (ITEM) 

FUSION.TIME  =  FUSION.C1. SERVICE  (ITEM) 

MULTIPLIER  =  1 
ELSEIF  (CLASS  .EQ.  CO)  THEN 

FIRST.TIME  «  FIRST  CO  SERVICE  (ITEM) 

CCNTINUED.TIME  =  CONT.CO.SERVICE  (ITEM) 

FUSION  TIME  =  FUSION.CO.SERVICE  (ITEM) 

.  MULTIPLIER  =  1 
ENDIF 

C  NON  SET  THE  RETURN  TIME  BASED  ON  THE  VALUES  HERE 

IF  ( (ATRI9  (CURR.SVS.TARFET)  .EQ.  TRUE)  .OR. 

1  (ATRIB  (ALERT.STATUS)  .EQ.  TRUE))  THEN 

FIRST.MESSA6E.TIME  =  EXPON (FIRST.TIME,  U 

CUHMI  NOTE  THE  CHAN6E  TO  EXPONENTIAL  FIRST  SERVICE  TIMES 
Cimmi  THE  ORIGINAL  COD  IS  COMMENTED  OUT  BELON 
C 

C  FIRST.ME-SA6E.TIME  =  UNFRM 

C  +  (LOW  LIM  MULT  I  C!RST  TIME, 

C  ♦  HIEH.LIH.MULT  )  FIRST.TIME,  1) 

ELSE 

FIRST. MESSAGE.TIME  =  UNFRM 
+  (LCW.LIM.MULT  *  CONTINUED.TIME, 

*  hish’lim'mult  *  continusd’time,  1) 

ENDIF 

r » 

C  IF  (FIFST. MESSAGE. TIME  .ST.  ICC)  THEN 

;  first_message_time  =  iso 


FUSION  sun  =  0.0 
DO  I  =  2,  MESSAGE.COUNT 

FUSIQN.SUN  =  FUSION  JUH  +  UNFRM 

'(LON.LMJIULT  *  FUSIONJIME, 

HIGH.LIM.MULT  »  FUSION  TIME,  11 

ENDDQ 

RETURN  TIME  =  MULTIPLIER  »  (FIRST  MESSAGE  TIME  +  FUSION  SUM) 

IF  (TRACE.ON  0)  THEN 
WRITE  (TRACEFILE,  t> 

WRITE  (TRACEFILE.  t)  . 

WRITE  (TRACEFILE,  ») 

TEMP.CURR.TIME  =  CURR.TIME  (1) 

WRITE  (TRACEFILE,  I)  ’CURRENT  TIME  =  TEMP_CURR_TIME 
WRITE  (TRACEFILE,  t)  ’BEGINNING  SERVICE  ON  MESSAGE  AT  ’, 

’NODE  ’,  CLASS.5TRING  (CLASS),  ’  ITEM 
WRITE  (TRACEFILE,  I)  ’PENETRATOR  TAIL  NUMBER  =  ’ ,  PEN 
WRITE  (TRACEFILE,  I) 

IF  ((ATRIB  (CURR_SYS.TARGET)  .EQ.  TRUE)  .OR. 

(ATRIB  (ALERT  STATUS)  .EQ.  TRUE))  THEN 
WRITE  (TRACEFILE,  t)  ’FIRST  REPORT'  BEING  PROCESSED’ 

ELSE 

WRITE  (TRACEFILE,  I)  ’CONTINUED  REPORT  BEING  PROCESSED’ 

EMDIF 

IF  (MESSA6E.C0UNT  .GT.  1)  THEN 

WRITE  (TRACEFILE,  t)  MESSAGE  COUNT,  ’  MESSAGES  MERGED  ’, 

►  ’TO  PRODUCE  THIS  REPORT’ 

ENDIF 

WRITE  (TRACEFILE,  t) 

WRITE  (TRACEFILE,  »)  ’FINAL  SERVICE  TIME  =  ’.  RETURN  TIME 
WRITE  (TRACEFILE,  »)  ’THIS  SERVICE  WILL  EE  COMPLETED'aT  ’, 

’TIME  TEMP  CHRP  TIME  +  RETURN  TIME 

WRITE  (TRACEFILE,  I) 

WRITE  (TRACEFILE,  I)  ’ - ’ 

WRITE  (TRACEFILE,  I) 
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TADZ  is  s.  camel  icated  model  consisting  of  both  SLAM  and 
F n p T F A P'-l  ~ a b  i  h d  •  F c? r*  t* h s  cur^css®  cp -f  +•  h o  rj. f f  s? zr  !■' p e t. c*. 1 1  ~  ~ 
used  i  r.  this  t  set  i  cs.l  scsnsriOj  the  user  nsec  only  be 
concerned  with  the  "incut  files"  and  1  mo 1 ementat i or 
procedures  for  TADZ.  This  append!:;  will  describe  the  input 
files  required  to  run  the  model  along  with  a  step  by  step 
implementation  guide.  The  basic  format  for  these  worksheets 
was  created  by  Mr.  Rick  Bowman.  FTD/TQC  C BOWMAN,  19853. 

Ingut  Files 

For  TADZ  to  model  even  the  simplest  of  tactical 
scenarios,  a.  minimum  of  thirty-one  input  files  must  be 
created  by  the  user.  There  are  four  major  classes  of  input 
data: 


1.  geography  of  the  air  defense  cone  (ADZ) 

2.  s', 'stem  o,_ de'~  of  battle 

3.  penetrator  order  of  battle 

4.  control  of  the  simulation  and  outputs 

This  user's  guide  will  essential  1 v  abbreviate  the  information 
that  is  found  in  the  TADZ  User’s  Guide  CMerriman  et  al , 

19843.  For  mere  detailed  ewplai nation  or  descriptions  of 


these  incut  tiles,  refer  to  that  reference.  Several  cf  the 
.  npu.t  files,  although  needed  to  run  the  model,  do  not  require 
user  mam  pul  at i on  for  the  tactical  scenario  used  here.  These 
files  will  not  be  described  in  this  appendi::,  however  the 
examples  of  each  type  of  input  file  are  provided  in  Append::: 
r ' 

ii'sLrid.-.L’BI-  This  file  is  the  first  file  read,  since  it 
contains  dimensioning  data  for  several  other  input  files. 
SYSLIM  sets  the  number  of  elements  in  the  C'"‘  system  being 
modeled,  to  include  the  number  of  "nodes"  in  the  network,  the 
number  of  penetrator  types,  and  the  number  cf  paths  or  routes 
used  by  those  penetrators.  All  these  parameters  are  bounded 
by  limits  which  are  set  in  the  global  parameter  file.  Care 
should  be  taken  not  to  exceed  these  limits,  although  the 
current  limits  are  set  well  above  the  numbers  required  to 
model  the  scenario  for  the  thesis.  Another  "caveat":  it  is 

CCitioal  to  keep  the  parameters  consistent  across  the  input 
files,  as  these  numbers  are  used  in  the  loading  of  the  common 
blocks  and  arrays  used  in  the  simulation. 


PARAMETER 


VALUE 


NUMBER 

OR 

R:!',:’ 

- 

(NUMRADAR) 

NUMBER 

0^ 

0  - 

s 

(NUM30) 

NUMBER 

OF 

_1 , 

s 

CNUMSl ) 

v.'-l’-V  i,  ’V  '~.V  - : 


■'  *  -*>  -SWCV:.  lAsVA1,' 


■.  j- 


J 
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NUMBER  OF  S^'s  (NUMS2)  MUST  =  1 

NUMBER  OF  C2’s  ( NUMC2 )  MUST  =  1 

NUMBER  OF  C1 7 s  (NUMC1) 

NUMBER  OF  C0;,s  (NUMCO) 

NUMBER  OF  PENETRATOR  TYPES  ( NUM^’EN TYPES  > 

NUMBER  OF  PENETRATOR  PATHS  < NUMPATHS ) 


The 


DAT. 


■files  include  site  and  tvpe  mt ormstic 


t  or  each  radar  set  modeled  in  the  system,.  Ir.  this  scenario, 

f'l 


there  are  7  R" ’ s  modeled:  tour  5AM  locations  and  three  EW 
radars.  The  EW  radars  are  co-located  and  are  needed  to  mode 
a  controller  tor  each  CAF'  point  within  the  ADZ.  The 
documentation  in  the  -following  example  describes  the  require 
in-formation  in  more  detail. 


PARAMETER 


VALUE 


LOCATION:  LAT,  LONE.  ALTITUDE 
( ROLOCAT I  ON ) 

TENTHS  OF  DEGREES,  METERS 
*  ALTITUDE  INCLUDES  ANTENNA  HEIGHT 


IDENTIFICATION  0!r  RADAR  TYPE: 

( EOT Y PE ) 

RELATIVE  POSITION  IN  EXEC  FILE 
E.G.  THE  FIFTH  RADAR  ON  THE  LIST 
IS  RADAR  TYPE  5 


NUMBER  O^  MASKING  ANGLES  WHERE  TERRAIN 
MASKING  OCCURS: 

( NUMMASI  - ANGLES ) 


MASK  AIMG_E  SPECIFICATIONS:  AZ  ELEV 

f.  MASK  ANGLES ) 

AZIMUTH  AND  ELEVATION  FOR  THE 
ANGLES  ABOVE 


STRUCTURE /HARDNESS  DESIGNATION  FOR  RADAR: 
(ROSTR'JCTURE) 

NOT  USED,  BUT  A  NUMBER  MUST  BE  INPUT' 


NUMBER  OF  S'"  SUPERVISORS  FOR  THIS  R": 
(NOROSO)  CAN  ONLY  HAVE  ONE! 


INDEX  OF  THE  S°  SUPERVISOR: 

(IROSO)  RELATIVE  POSITION  IN  EXEC  FILE 


TIME  TO  PROCESS  FIRST  REPORTS  (SECONDS): 
( p-  p  st  ROSE  R  V  ICE) 


TIME  TO  PROCESS  CONTINUED  REPORTS  (SECONDS) 
(CONTROSERVCE) 


TIME  TO  FUSE  TWO  MESSAGES: 
( FU5NR0SERV I CE ) 


These  -files  contain  the  descriptions  o-f  the 


SO;-:  .  DAT . 

n  I 

b  7 s  in  the  network.  The  information  required  is  quite 

similar  to  the  RO:; .  DAT  files.  For  the  tactical  scenario 

o 

chosen  for  this  project,  the  number  of  b  ’ s  is  equal  tc  the 
number  of  R<_  7  s .  Again,  the  s:-plainations  in  the  example  file 
should  clarify  any  questions  that  arise.  One  caution  in  this 
file:  when  describing  the  connectivity  from  the  S',  this 

node  can  be  linked  to  either  an  S*  or  an  S'"  node  but  not 
both.  The  region  of  responsibility  for  an  S*'1  is  defined 
implicitly  as  the  union  of  the  regions  of  all  the  radars;  that 
report  to  it. 


PARAMETER 


VALUE 


LOCATION:  LAT,  LONG,  ALT 

TENTHS  OF  DEGREES,  METERS 
( 30L0CAT I ON ) 


STRUCTURE /HARDNESS  DES I GNAT I  ON : 
( SOSTRUCTURE ) 


1 


NOME EE  OF  S'  SUPERVISORS  FOR  THIS 
SJ  ( NOS OS  1 )  : 

MUST  BE  EITHER  0  OR  1 

CAN  BE  LINKED  WITH  AN  S1  OR  S^, 

BUT  NOT  BOTH1 


INDEX  OF  E1  SUPER  (IE0S1): 

RELATIVE  POSITION  IN  EXEC  FILE 
LEAVE  BLANK  IF  NO  S1  SUPERS 


NL'MEEF:  OF  C  NODES  CONNECTED  TO  THIS  S'*: 

(NOSOCo)  MUST  BE  EITHER  0  OR  1,  CAN  BE  LINKED 
TO  A  C"  OR  C1  BUT  NOT  BOTH' 


INDEX  OF  C°  SUPER  (ISOCO): 

RELATIVE  POSITION  IN  EXEC  FILE 
BLANK  IF  NO  C"  LINK 


NUMBER  OF  C1  CONNECTIONS  (NOSOCl): 
MUST  BE  0  OR  1 


INDEX  OF  C1  SUPER  (ISOC1): 


NUMBER  OF  S2  SUPERVISORS  (N0S0S2)  : 
MUST  BE  0  OR  1 


INDEX  OF  32  SUPER  (1 5032): 
LEAVE  BLANK  IF  NONE 


TIME  TO  PROCESS  FIRST  REPORTS  (FRSTSOSERVICE) : 
IN  SECONDS 


TIME  TO  PROCESS  CONTINUED  REPORTS 
( CQNTSOSERV I CE )  :  IN  SECQNDE3 


TIME  TO  FUSE  TWO  MESSAGES  ON  SAME  TARGET 
( FUSN30SERV I CE ) :  IN  SECONDS 


S3.xMi.DAI.  This  -file  contains  much  the  same  i  n-f  ormati  on 
required  in  the  30:; .  DAT  -files.  The  node  is  -found  one 
level  "up "  the  heirarchy  in  the  C'  network.  The  last  two 
van  dies  in  this  tvpe  of  file  (SI _S2_BELECT  and 
3 1 _32_MULTIPLIER)  are  used  when  the  network  must  be 
reconfigured  when  nodes  are  destroyed  by  the  attacking 
penetrators.  This  effort  did  not  employ  this  capability  of 
TADZ.  The  interested  user  is  referred  to  the  TADZ  User’s 
Guide  for  more  information  on  this  subject  CMerriman  et  al , 
1984: 69,703. 


PARAMETER 


LOCATION  (S1L0CATI0N) : 
LAT.  LONG,  ELEV. 


STRUCTURE/HARDNESS  ( S 1  STRUCTURE  > : 


NUMBER  OF  S"  SUPERS  FOR  THIS  S  s 
(NOS ISO)  MUST  BE  0  OR  1 


INDEX  OF  THE  S'*-  SUPER  (IS ISO): 

RELATIVE  POSTITION  IN  EXEC  FILE 


NUMBER  OF  C1  LINKS  TO  THIS  S1: 
(NOS 1 Cl)  MUST  BE  O  OR  1 


INDEX  OF  THE  C1  SUPER  (IS1C1): 

RELATIVE  POSITION  IN  EXEC  FILE 


VALUE 


.'-v-rc-z-rz- .  • . 
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PROCESS  TIME  FOR  FIRST  REPORTS: 
(FRSTS1 SERVICE)  IN  SECONDS 


!ME  FOR  CONTINUED  REPORTS: 

(CONTS1 SERVICE)  IN  SECONDS 


TINE  TO  FUSE  TWO  REPORTS  (FUSNS1 SERVICE) : 


■;ELATC,VE  PRIORITY  FOR  THIS  S  TO  REPLACE 
S"  (S1S2SELECT) : 

INPUT  REQUIRED,  BUT  NOT  MODELED  IN  THIS 
SCENARIO 


PERFORMANCE  CAPABILITY  AS  3“ : 
(S1S2MULTI FLIER)  7.  OF  ORIGINAL  S' 
CAF'ABL  I TY 


.'-V' •>_ *%y> -  v-  j 


2i=Ll'li.k‘0I-  The  5  nodes  are  vet  another  step  up  the 
network  “chain".  These  nodes  are  described  in  the  same 

manner  as  the  EU  and  5^  nodes.  The  region  of  responsibi 

n  O 

of  the  S'-  is  the  union  of  the  regions  defined  in  the  u ' 

S^  input  files  “below"  or  reporting  to  it. 


PARAMETER 


VALUE 


LQCAT I  ON  ( S2LGCAT I ON > : 

TENTHS  OF  DEGREES,  METERS 


STRUCTURE / HARDNESS  ( S2STRUCTURE > : 
NOT  USED  IN  THIS  SCENARIO,  BUT 
MUST  INPUT  A  NUMBER! 


NUMBER  OF  O'"  SUPERS  FOR  THIS  S' 
( NOS 202  >  MUST  BE  1! 


INDEX  OF  C~  SUPERVISOR  (IS2C2): 

RELATIVE  POSITION  IN  EXEC  FILE 


FIRST  REPORT  PROCESS  TIME  (FRSTS2SERVICE) 


DMTINUED  REPORT  SEP'.’ ICE  TIME  ( 00NTS2SEPV I CE )  : 


FUSION  TIME  FOR  MESSAGES  (FUSNS2SERVICE) : 


B- 10 


...  *  .  ■  ■  ** .  '  ■  ...  '  * .  ..........  "  ■ '  . 

■*  fc  *  -  ■  m  ►  .1 


Ssiy-iiL’tf!!*  This  -file  contains  the  information  descr i bi n 
this  t.rst  or  upper  level  a- f  the  "command"  structure  o*  the 
network.  An  explicit  geographic  area  of  responsibility  is 

given  in  this  file.  This  area  is  actually  the  outer  boundary 
or  overall  ADZ  region.  The  elevations  of  the  boundary  point 
are  not  required  here  as  the  airspace  is  assumed  to  extend 
from  the  ground  to  infinity  above  the  defined  region.  Note 
that  there  are  no  network  connections  described  in  this  file 

All  required  connections  are  given  in  the  appropriate  S~,  C1 

O 

and  C  input  files. 


PARAMETER 


VALUE 


LOCATION  (COLOCATION): 

LAT,  LONG,  ALTITUDE 

TENTHS  OF  DEGREES  AND  METERS 


STRUCTURE /HARDNESS  DESIGNATION  (COSTRUCTURE) 
NOT  USED,  BUT  INF'UT  IS  REQUIRED 


NUMBER  OF  C^  BOUNDARY  POINTS  (COGBOUND) : 

MAX  OF  00  POINTS  TO  DESCRIBE  THE  AREA  OF 
RESPONSIBILITY  OF  THE  C" 


LAT,  LONG  OF  BOUNDARY  POINTS  (COBOUNDARY) 
TENTHS  OF  DEGREES 


FIRST  CT  SERVICE  TIME  < FRSTC2SERV I CE ) : 
IN  SECONDS — TIME  TO  MAKE  ASSIGNMENT 
MODELED  AS  O  IN  THIS  SCENARIO 


CONTINUED  C"  SERVICE  TIME  (CONTC2SEPVICE)  :  0 

IN  SECONDS 


TIME  TO  FUSE  TWO  MESSAGES  ON  SAME  TRACK: 
( FU3NC2SEEV I CE )  IN  SECONDS 


Si'illi.DBI"  This  -file  contains  the  information  describing 
the  command  level  just  above  the  missile  sites.  In  the  TAGS 
scenario  this  node  represents  the  ADLO  located  in  the  CRC. 


PARAMETER 


VALUE 


LDCAT I ON  ( C 1 LOCAT I  ON ) : 

LAT,  LONG.  ALT  (TENTHS  OF  DEGREES) 


STRUCTURE  ( C 1  STRUCTURE ) 

NOT  USED  IN  THE  TACTICAL  SCENARIO 


NUMBER  OF 
(MAX  OF 


BOUNDARY  POINTS 
20 ) 


(C1GB0UND) 


LAT,  LONG 
(TENTHS 


OF  BOUNDARY  POINTS  (Cl BOUNDARY) 
OF  DEGREES) 


LAT: 


LONG: 


NUMBER  OF  C~  SUPERVISORS  (N0C1C2) 

(EITHER  0  OR  1)  1 


INDEX  OF  C*-  SUPER  (IC1C2) 

(RELATIVE  POSITION  IN  EXEC  FILE 

LEAVE  BLANK  IF  NONE)  1 


TIME  TO  EVAL  ASSIGNMENT  STATUS  AND 

MAKE  ASSIGNMENT  OR  HANDOVER  (SECONDS) 
(FRSTC1 SERVICE) 


TIME  TO  SEND  TRACK  DATA  TO  Cs 
UNDER  CT  CONTROL  (SECS) 

( CONTC 1 3ERV I CE ) 


B- 1 3 


0 


LAT,  LONG, ALT  OF  EACH  POINT  ALONG 
PATH  (TENTHS  OF  DEGREES,  METERS) 

<  I  PC'  I  NTS  I  ) 

**  FIRST  POINT„DF  THE  PATH  MUSJ  LIE 
OUTSIDE  OF  O'"  BOUNDARY  AND  ALL 


PENS I . DAT 


,  .it-  «. 


This  tile  contains  the  descriptions 


di-frerent  penetrator  types  being  modeled  in  the  scenario. 
E:;amol5s:  l=Fo:;bat,  2=Flogger,  3=Bear.  Maximum  o-f  4  tvpe 

mav  be  ascribed.  The  relative  position  o-f  the  penetrator 


this  till 


:he  prosecution  priority  ct  that  tv 


VALUE 


e.q,  type  1  is  the  highest  priority, 


F:  ARAMETER 


INDEX/ ID  OF  PENETRATOR  TYPE 
(PEN  TYPE) 


PENETRATOR  VELOCITY  (M/SEC ) 
(PENSPEED) 


PENETRATOR  RADAR  CROSS  SECTION  (hT) 
(F ENGROSS) 


NUMBER  OF  WARHEADS  BY  TYPE  CARRIED 

BY  THE  PENETRATOR.  MUST  HAVE  5  ENTRIES 
EVEN  IF  LESS  THAN  5  WARHEADS  DEFINED  IN 
WRHEAD .  DAT  F I LE .  ( F'ENBOMBS)  E .  6 .  4,8.0,  0 , 0 


EC"'  XhFP-  POWER  (WATTS' /MHZ) 

TADZ  REQUIRES  TWO  VALUES.  2nd  NOT 
CURRENT..^  USED  (ECMPOWER) 

%t  REPEAT  THE  ABOVE  VALUES  FOR  UP  TO  4  PEN_TYPES . 
NUMBER  DEFINED  MUST  AGREE  WITH  SYSLIM.DAT. 


PKBLK'^DhT.  This  '"lie  contains  the  information  -for  the 
snore  >'snge  PIT’s  of  the  oenetrators  against  the  fighter 
interoBOtors  (FI's)  .  The  ".matri :: "  size  will  be  the  number  of 
pari~tr5tor  t  /pea  by  the  rumpe*'  of  FI  types  as  defined  in  the 
FEME  I .  DAT  and  WEPAF;A.  DAT  INFL’T  files  respectively. 

PARAMETER  VALUE 

PROBABILITY  OF  FILL  MATRIX  FI-1  FI -2  FI -3  . 

( PEN_ON_ UN I T ) 

PEN-1 
PEN-2 
PEN -3 
PEN-4 

*  VALUES  IN  THE  MATRIX  RANGE  FROM  O  TO  1.0.  THESE  VALUES 
SHOULD  ONLY  BE  NON-ZERO  IF  THE  PENETRATOF:  ACTUALLY  HAS  THE 
CAPABILITY  TO  FIRE  SHORT  RANGE  GUNS  OR  MISSILES  AGAINST  FI's. 


WRHEAD^DAT.  This  aata  -file  contains  the  spec  i  f  i  cat  i  cns 
•  for  the  warheads  for  the  genet rator s .  These  warhead  types 

can  be  defined  whether  or  not  the  F'K's  are  greater  than  zero 
i n  t h e  P K B LK . DAT  file. 


PARAMETER  VALUE 


NUMBER  OF  PENETRATOR  WARHEAD  TYPES 
MAX  OF  5.  ( NUMWRHEADS) 


WARHEAD  RANGE  IN  METERS 
( WHRANGE ) 


WARHEAD  CLASS  ( I =GR AV I TV  BOMB; 
2-3ELF-RR0PELLED ) 

( NWHTYRE ) 


WARHEAD  SPEED  IN  M/SEC 
(WHS PEED) 


WARHEAD  YIELD  IN  KILOTONS 
(WHY I  ELD) 


AD-A172  447 
UNCLASSIFIED 
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y5ti-6L!i.£.'6I  •  This  data  file  contains  the  specif  icaticns 
•  for  the  warheads  far  the  ££Q§t rators .  These  warhead  types 

can  be  defined  whether  or  not  the  PK’s  are  greater  than  :ero 
i  n  t  h  e  RKBLK .  DAT  file. 


PARAMETER  VALUE 


NUMBER  OF  PENETRATGR  WARHEAD  TYRES 
MAX  DF  5.  ( NUMWRHE ABS ) 


WARHEAD  RANGE  IN  METERS 
<  WHRANGE ) 


WARHEAD  CLASS  ( 1 =GRAV I TY  BOMB; 
2=3ELF-PR0RELLED ) 

( NWHTYPE ) 


WARHEAD  SPEED  IN  M/SEC 
(WHSPEED) 


WARHEAD  YIELD  IN  KILOTONS 
(WHY I ELD) 


B-1B 


WHF;ARAi.pAI.  This  -file  contains  the  data  -For  the  weapon; 
used  by  the  tighter  interceptors  and  the  surface  to  air 
missiles  against  the  per.trators  ( e .  g  .  air-to-air  missiles, 
a  an  s .  and  SAM's). 


PARAMETERS 


NUMBER  QF  FI  WARHEAD  TYPES 
<FI_NUM_WH)  INTEGER  NO. 
E.G.  AIM?,  A I M9 ,  GUNS  =  3. 


NUMBER  OF  MI  (SAM)  WARHEADS 
( M I _NUM_WH )  INTEGER  NO. 

E.G.  HAWK  MISSILE  =  1. 


MATRIX  OF  WARHEAD  PK' s 
ROWS  a  WH  TYPES, 

COLUMNS  =  PENETRATOR  TYPES 
(PK  S3) 


NO.  OF  WARHEADS  PER  SALVO 
FOR  EACH  WH  TYPE,  INTEGER 
(SET  TO  ONE  IN  THESIS) 
(SHOOT) 


MAXIMUM  LAUNCH  RANGE  FOR  EACH 
WARHEAD /MISSILE  TYPE,  METERS 
♦SET  TO  0  FOR  MI  WH’s 
(RLAUNCH) 


VALUES 


PEN#  1 


PEN#' 


FI  WH  1 


FI  WH  2 


FI  WH  3 


MI  WH  1 


MINIMUM  ASPECT  ANGLE  FOP  FI  WH’s 
*  INPUT  FOR  AIR  TO  AIR  MISSILES  ONLY 
UNITS  =  RADIANS  (ASPMIN) 


MAXIMUM  ASPECT  ANGLE  FOR  FI  WH’s 
( ASPMAX ) 


WARHEAD  SPEEDS  IN  METERS/EEC 
FOR  ALL  WH  TYPES  (VWHEAD) 


MATRIX  OF  FIGHTER  INTERCEPTOR  WH  LOADS  FI  TYPE  1 

ROW  =  WH  TYPES,  COL  =  FI  TYPES 
( INITWH) 


AIM7 


BASES^DAI.  This  -file  simply  lists  the  -fighter 


interceptor  bases  and  their  locations.  There  is  also  a 
parameter  -for  -fighter  service  times.  Appendix  C  has  an 
example  c-f  this  -file. 


PARAMETERS 


VALUES 


FIGHTER  "TURN"  TIME  AT  THE  BASE 
UNITS  ARE  SECONDS  (BASESERVICETIME) 


NUMBER  OF  AIRBASES,  MAX  OF  10 
RECOMMEND  ONE  BASE  PER  CAR 
(NAIRBA3ES) 


LOCATION  OF  AIRBASES 
LAT,  LONG,  ALTITUDE 
TENTHS  OF  DEGREES  AND  METERS 
ONE  LINE  PER  BASE  (BASEL I ST) 


B-21 


PENTIM. DAT 


This:  -file  contains  parameters  that  TADZ 


uses  to  generate  penetrator  arrival  times.  The  parameters 
describe  "pulses"  along  a  penetrator  path.  Each  pulse  is 
char  acter  1  z  ed  by  the  -five  parameters  listed  below.  This  -file 
is  perhaps  the  most  difficult  to  understand.  Refer  to  the 
TADZ  User's  Maunual  -for  -further  details  CMerriman  et  al  , 
198^:3.543.  An  example  is  supplied  in  Appendi:;  C. 


\ 

\ 

LAH0PA.ZMIT 

\ 


\ - T_PUL$E5_IN1T  CTME  INITIAL  TIME  OF  THE  PULSE) 


WHERE: 


LAMBDA_INIT  -  MAXIMUM  ARRIVAL  RATE  DF  THE  PENETRATDRE  IN 
THE  PULSE  (NO.  OF  c‘ENETRATORS  PER  SECOND).  LAMBDA_ I N I T  >  0. 

T_PULSEE_INIT  =  TIME  IN  SECONDS  AT  WHICH  EACH  PULSE 
BEGINS.  MUST  BE~GREATER  THAN  OR  EQUAL  TO  ZERO. 

TAU_R_1N1T  =  THE  LENGTH  OF  TIME  OVER  WHICH  THE  ARRIVAL 
RATE  0C:'  THE  PENETRATORS  INCREASES  (SECONDS'.  MUST  BE  GREATER  THAN 
OR  EQUAL  TO  ZERO. 

TAU_C_ INI T  =  THE  LENGTH  OF  TIME  OVER  WHICH  THE  ARRIVAL 
RATE  0C  THE  PENETRATORS  REMAINS  CONSTANT  ( SECONDS ) .  MUST  BE 
GREATER  THAN  OR  EQUAL  TO  ZERO. 

TAU_F_IN:T  =  THE  LENGTH  DF  TIME  OVER  WHICH  THE  ARRIVAL 
FATE  THE  PENETRATORS  DECREASES  (SECONDS).  MUST  BE  GREATER  THAN 
OR  EQUAL  TO  ZERO. 


T  C 


**  NOTE:  THE  NUMBER  OF  F'ENETRATORE  FOUND  IN  A  GIVEN  F'U 
DEFINED  BY  THE  AREA  OF  THE  PULSE  AS  SHOWN  ABOVE.  I.E. 


qp 


AREA  -  LAMBDA  I  NIT  #  (TA'J  R  I  NIT/2  +  TAU  0  I  NIT  +  TAL1  F  INIT/2; 


y* 


> 


EXAMPLE:  DEFINE  ONE  PENETRATOF.  PER  PULSE.  .  .  . 

LET  TAUJR.INIT  =  0:  TAU_F_1NIT  =  0;  TAU  C  I NIT  *  1: 
LAMBDA_ I NIT  =1. 

THE  AREA  OR  NUMBER  OF  PENETRATORS  IN  THE  PULSE  WILL  BE.... 
1 t ( 0 / 2  +  1  +  0/2)  =  1 

====:•  A  5TNGLE  PENETRATOF:  WILL  ARRIVE  BETWEEN  T 

T  PULSES  IN  I T  AND  T  PULSES  INIT  +  1  SECONDS 


PARAMETER 


VALUE 


[>:  NUMBER  OF  PATHS  USED  BY  PENETRATOR 
m  CANNOT  EXCEED  NUMBER  IN  SYSLIM.DAT 
P  (N  RAID  PATHS) 


> 


1 


ft 


***  POP  EACH  PATH  YOU  DESIRE  TO  "SEND"  PENETRATORS  DOWN.  THE 
FOLLOWING  PARAMETERS  MUST  BE  DEFINED... 


THE  SPECIFIC  PATH  USED  IN  THIS  PULSE 
RELATIVE  POSITION  IN  PATHSI.DAT 
(RAIDPATHS) 


NUMBER  OF  DIFFERENT  PENETRATOR  TYPES 
USED  ON  THIS  PATH  (NPTYPES) 

**  FOR  EACH  PENETRATOR  TYPE  USED  ON  THIS  RATH,  DEFINE  THE 
FOLLOWING  PARAMETERS... 


K 


K 


PENETRATOR  TYPE  USED 
( F'TYF'ES ) 


NUMBER  OF  ARRIVAL  PULSES  FOP 
EACH  PENETRATOR  TYPE  ( NF'ULSE INIT) 
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*  FOR  EACH  PULSE  DEFINE 

PARAMETERS  FOR  EACH 
INDIVIDUAL  PULSE  (PULSE) 

LAMBDA, I NIT 

T  AL'_R_  I N I T 

TAU_C_INIT 

TAU_F_INIT 

T_PULSES_ I N I T 

NOTE:  THIS  FILE  ESSENTIALLY  CONSISTS  OF  TRIPLE  NESTED  LOOPS... 

I  =  1  TO  NUMBER  OF  RAID  PATHS 

J  =  1  TO  NO.  OF  PENETRATOR  TYPES  ON  THE  PATH 

K  =  1  TO  NO.  PULSES  PER  PEN.  TYPE  ON  THE  PATH 


B-24 


QOli^DAI.  This  -file  type  contains  the  information  that 

o  * 

describes  the  C  7 s  m  the  scenario.  There  can  be  two  types 
of  C°7s:  the  FI  and  MI  or  fighter  and  SAM  types.  Within  th 
file  or  sequence  of  files  the  FI  C°'s  must  be  defined  first. 
Some  parameters  in  this  file  are  specific  to  only  one  or  the 
other  of  the  types  (MI  or  FI).  These  will  be  pointed  out  in 
the  following  parameter  list. 


PARAMETER  VALUE 


CU  TYPE  DESIGNATION 
EITHER  FI  OR  MI  (COTYPE) 


C°  OPERATES  AUTONOMOUSLY 
TRUE  OR  FALSE  (COAUTO) 


LOCATION  OF  THE  C<J 

LAT,  LONG,  ALTITUDE  (COLOCATION) 


STRUCTURE  DESIGNATION  (COSTRUCTURE) 


NUMBER  OP  c'3 1  NTS  IN  C°  BOUNDARY 
MAX  OF  20  POINTS  (COGBDUND) 


LAT.  LONG  OF  BOUNDARY  POINTS 


MI  C°  LETHAL  REGION  OF  COVERAGE 

EXPRESSED  AS  PARABOLOID  WITH 

XO  =  LAT.  RANGE;  YO  =  LONG.  RANGE; 

ZO  =  ALTITUDE  RANGE;  ALL  IN  METERS 
(COFBOUND)  *USE  DUMMY  VALUES  FOP  FI. 


1 


LAT  LONG 


NUMBER  OF  C  EUPERE  FOR  THIE  C 
(COC1 ) 


INDEX  OF  C1  SUPER  (RELATIVE  POSITION 
IN  EXEC  FILE)  LEAVE  BLANK  IF  NO  C1  SUPER. 
( I COC1 ) 

NO.  0-  C^  SUPERS  FOR  THIS  C° 

(COCO) 

INDEX  OF  CT  SUPER,  LEAVE  BLANK  IF  NONE 
( I COCO) 


TIME  TO  PROCESS  FIRST  REPORT  (FRSTCOSERVICE 


TIME  TO  PROCESS  CONTINUED  REPORTS 
(CONTCOSERVICE) 


TIME  TO  FUSE  TWO  MESSAGES  ON  SAME  TARGET 
( FUSNCOSERV I CE ) 


LOITER  POINT  FOR  FI  C° 

LAT.  LONG,  ALT  (LOITERPOINT) 
*  LEAVE  BLANK  IF  MI  C '* 


BASE  THAT  SERVICES  C  AIRCRAFT 
RELATIVE  POSITION  IN  BASES . DAT  FILE 
( BA3ENUMBER )  LEAVE  BLANK  IF  MI 


NUMBER  OF  501  OR  FIRE  CONTROLLERS 
AVAILABLE  FOR  THIE  C°  (NUMOFSERVERS) 


TOTAL  NUMBER  OF  FI/MI  TYRES... 

FOR  FI ,  SPECIFY  TOTAL  NO.  OF  FI  TYREE 
FOR  MI,  SPECIFY  TOTAL  FI  MI  TYPES 
(NUN I TYPES) 


THE  R 

OLLOWIN1 

THESE 

T  Y  p  c:  c: 

SEQUEN 

OE  v  I .  E 

N  .  LE . 

1  4  A  R 

FI  ’  = 

AND  PO 

ENTRY 

FOF:  Eh: 

ACCORD 

ING  TO 

AND  MI 

TYPES . 

r  r- 

"r' 

SEQUENCE  vI.E.  TYPE  1,2,...  N  .  LE.  4  ARE  FI  T(s'F'E5 :  WHI_E  2.  a,.. 
K  .LE.  14  ARE  MI  TYPES) .  EVEN  THOUGH  A  MI  2°  DOES  NOT  HAVE  AN 
FI ’  s  AND  POE El PLY  NOT  CERTAIN  TYPES  OF  Mi's,  TALC  -ECU I REE  A 
ENTRY  FOR  EACH  WEAPON  TYPE  (I.E.  J  =  1,2,....N'.  PROVIDE  DAT 
ACCORDING  TO  THE  PARAMETER  TEMPLATE  FOF  TYPE  1  •  J=l  :•  FOR  A1.L  F 


A  LOOP :  J  =  1  TO  NUUN I TTYPES , 


NUMBER  OF  UNITS  BY  TYPE  (NUMUNITS) 

"OR  FI  THE  NO.  OR  FLIGHTS 
FOP  Ml  THE  NUMBER  OF  LAUNCHERS 
*  SET  =  0  IF  THIS  J  (MI  OR  FI  TYPE) 
DOES  NOT  E X  I £ T  AT  THIS  C J 


INDEX  OF  UNIT  TYRE  CORRESPONDING 
TO  POITION  IN  WEPARA.DAT  (COUNITS) 


NUMBER  OF  WEAPONS  PER  UNIT  ( INITWEAPONS) 
FOP  FTs,  NO.  OF  AIRCRAFT  PER  FLIGHT 
E.G.  2,2,2 

FOF  MlNs.  NO.  OF  MISSILES  PER  LAUNCHER 
E .  G .  3 , 3  3 , 3 


UNIT  CONTROL  POLICIES  (INITCONT) 
ONLY  REQUIRED  FOR  FI’s 
SPECIFY  FOR  EACH  FLIGHT 
E.G.  TITE, TITE, LOOS, LOOS. . . 


UN I "  S TATUS  < I N I TUN 1 TSTAT ' 

ROR  FI’s,  SPECIFY  FOR  EACH  FLIGHT 
E.G.  LOIT, LQIT 

*  ONLY  LOIT  IS  ENABLED  IN  CURRENT  TAD! 
FOR  Mi’s,  STATUS  OF  EACH  LAUNCHER 
E.G.  READ, READ, READ 


Fi_l.e.  "This  -file  "tells"  TADZ  where  to  look 
-for  the  required  input  date.  TEST.DAT  is  the  file  name  used 
in  this  tactical  version.  Within  TEST.DAT,  the  files  are 
simply  listed  in  a  logical  order  along  with  some 
documentation  concerning  the  purpose  of  the  various  input 
files.  This  is  a  simple  but  important  input  file.  Refer  to 
Append::-  C  for  an  example. 

RADARx^pAJ.  The  technical  spec i f i cat i ons  for  each  radar 
type  used  m  the  simulation  are  included  in  this  file.  For 
this  scenario,  only  two  different  types  are  used:  the  TPS43 
EW  radar  and  the  HAWK  acquisition  radar.  The  variable 
NUH_RAE'AR_TYPE  must  be  included  as  the  first  input  in  the 
first  radar  file  read  in,  but  is  not  included  in  subsequent 
,  edar  files.  In  this  case,  NUM_RADAR_TYPE  is  set  equal  to  2 
since  the^e  are  two  radar  types  modeled  in  the  scenario. 
Consequently,  there  should  be  two  radar  files  created 
' RADAR  1 . DAT  and  RADAR2.DAT  for  example). 

B0D0BI0l!iO0I ■  This  file  contains  the  radar  pulse 
integration  table.  This  table  contains  the  si gnal -to-noi se 
ratio  (d£)  needed  to  allow  for  a  50V.  chance  of  detecting  a 
target  given  a  certain  number  of  integrated  pulses.  This 
figure  is  used  in  the  calculation  of  radar  burnthrough  range. 
Appendi::  C  contains  working  examples  of  the  two  radar  files. 


H 

H  THIS  !:  THE  EXECUTIVE  DATA  SET  FCF:  THE  TAD2  SIMULATIO! 
H  ZOKTAZKES  IS  THIS  FILE  IS  ALL  STATIC  CONTROL  DATA  LOAI 
H  DISK 

H 

g  EYE1  II1 

B 

B  SFECIFICATIONS  OS  THE  VARIOUS  NUMBERS  OF  SYSTEM  TYPE  ! 

E  IK  THE  CC  SYSTEM 

E 

'TEST: 5YSLIM1.DAT’ 

I 

B  RADAR 

B 

B  RADAR  SET  SPECIFICATION  DATA 

B 

’TEST: RADAR1.DAT’ 

’TEST: RADAR". DAT’ 

’TEST: RADAR3.DAT’ 

’TEST: RADAR4.DAT* 

’TEST.-RADAR5.DAT’ 

’TEST: RADARi.DAT’ 

’TEST: RADARTAB.DAT’ 

* 

B  ROINIT 

B 

B  INITIAL  RADAR  SPECIFICATIONS 

B 

’TEST.-R01ECI1.DAT’ 

’TEST:RCCcCI2.DAT’ 

’TEST: R035CII.DAT’ 

'TEST: R04SAK1.DAT' 

’ TEST : R05SAM2 . DAT  ’ 

’TEST: R0sSAK3.DAT’ 

’ TEST : R07SAM4 . DAT  ’ 

I 

B  SOINIT 

B 

B  IKITIfi-  e"  Ecr"IFICA"InN: 

B 

’TESTjSOISCII.DAT’ 

’TEST: 5C25CI2.DAT’ 

’ TEST : S03BCI3.DAT ’ 

'TEST: S04SAM.DAT’ 

’ TEST :S055fiH2.  DAT’ 

’TEST  :S06SAf!3.DAT’ 

’TEST: S07SAN4.DAT’ 


’ TEST : £1 01 . DAT’ 


INITIAL  SI  SPECIFICATIONS 


’TEST: SCCI. SAT’ 


CCINIT 


INITIAL  ::  SP£CIF!CAT!ONS 


’ TEST : C20i.DAT’ 


C1INIT 


INITIAL  Cl  SPECIFICATIONS 


’ T£ST : C101 . DAT’ 


COINIT 


INITIAL  CO  ASSETS 


THE  DATA  FILES  FDP  THE  CO  ASSETS 


’ TEST : COIF! 1 .DAT’ 
'TEST: C02FI2.DAT’ 
’TEST: C03FI3.DAT’ 
’TEST: C04HX1.DAT* 
’TESTjC05HI2.DAT’ 
’TEST: C06MI3.DAT’ 
’TEST: C07KI4.DAT  ’ 


WEPARA 


SYSTEM  WEAPON  PARAMETERS 


’  TEST :  WEPARA  .DAT’ 


WHPARA 


SYSTEM  WARHEAD  PARAMETERS 


'TEST: WHPARA, DAT’ 


COPARA 


CO  PARAMETERS 


’TEST: COPARA. DAT’ 

BASES 

LOCATIONS  OF  SYSTEM  AIR  BASES 
’TEST: BASES. DAT’ 

PATHSI 

PENETRATION  PATH  DATA 
’TEST: PATHS  I. DAT’ 

PENSI 

DESCRIPTION  OF  THE  PENETRATOR  TYPES 
’ TEST: RENSI . DAT ’ 

PENTIM 

PENETRATION  RAID  GENERATION  DATA 
’TEST: PENTIM.DAT’ 

TARGET 

SPECIFICATIONS  FOR  PENETRATOR  TARGET  STRIKES 
’TEST: NOTARGETS. DAT’ 

HRHEAB 

CAPABILITIES  OF  THE  PENETRATOR  WARHEADS 
’TEST: WRHEAD.DAT’ 

COORD 

THE  COORDINATE  INFORMATION  BLOCK 
’TEST: COORD. DAT’ 

PKBLK 

PK’S  FOR  PENETRATORS  AGAINST  UNITS 
’TEST: PKBLK. DAT’ 


COPRI 


ORDERING  Cf  SERVICES  C0F;  THE  CO  QUEUES 


’TEST:  COP®!. Mr 
STRUCT 

HARDNESS  TYPES  CF  C3  SYSTEM  ELEMENTS 
’ TEST: STRUCT. DAT' 

R UNCON 

EXECUTION  CONTROL  DAT fi 
’TEST: RUNCCN.DAT’ 

SLNCON 

CONTROL  DATA  FOP  SLAM 
’TEST: SLMCQN.DAT’ 

STTCQN 

CONTROL  OF  STATISTICS  COLLECTION.  AND  NUMBER  OF  REPLICATIONS 
’TEST: STTCDN.DAT' 

AESFLS 

AGGREGATE  STATISTICS  OPTIONS 
’TEST: A5SFLS.DAT’ 

SEEDS 

INITIAL  VALUES  OF  THE  RANDOM  NUMBER  SEEDS 
’TEST: SEEDS1. DAT’ 

CMINPT 

MESSAGE  DELAYS  (PERHAPS  GENERATED  BY  THE  COMMUNICATION  MODELS) 
’TEST: CMINPTC.DAT’ 

SNITCH 

CENTRALIZED  OF  DECENTRALIZED  EXECUTION 
’ TEST : SWITCHES. DAT’ 


R 

eve?  TM 

V 

INTEGER  NUflRADAfr - 

— NUMBER  OF  RADARS  IN  THE  C3  SYSTEM 

r 

KUKRADAR 

7 

V 

INTEGER  NUM50 - 

--NUMBER  OF  SO’S  IN  THE  C3  SYSTEM 

N'JMSO 

7 

INTEGER  NUNS1 - 

V 

—NUMBER  OF  SI’S  IN  THE  C3  SYSTEM 

r 

NUM51 

1 

INTE5ER  MUMS' . - 

V 

—NUMBER;  Oc  SI’S  IN  THE  03  SYSTEM 

r 

NIR1S2 

1 

INTEGER  NUNC: - 

V 

—NUMBER  OF  Cl’S  IN  THE  03  SYSTEM 

r 

wmc2 

i 

INTEEER  NUHC1 - 

V 

—NUMBER  OF  Cl’S  IN  THE  03  SYSTEM 

r 

Nirnci 

l 

INTEGER  NUUCO - 

V 

—NUMBER  OF  CO’S  IN  THE  03  SYSTEM 

C 

NUP1C0 

7 

V 

INTEGER  NU(1  PEN  TYPES— 

—NUMBER  OF  PENETRATOR  TYPES  ACTUALLY 

V 

- USED  IN  SCENARIO 

F 

NUWPENTYPES 

7 

V 

i 

INTEGER  NUMPATHS - 

—THE  NUMBER  OF  PATHS  USED  IN  THI5 

V 

SCENARIO 

NUMPATHS 


R  RADARSEQ 

V 

V  FOR  1=1. MUM_RADAR_TYPE  SPECIFY  THE  FOLLOW I N6 

V 

V  1=3 

V 

V  REAL  RADAR.FREOUENCYtl) - RADAR  CENTER  FREQUENCY  (MHZ) 

*  RFREQUENCY 
3000 

V  REAL  RADAR_POMER { I ) — RADAR  TRANSMISSION  POWER  (KN> 

c  RPOWER 

6.7 

V  REAL  RADAR.PRF(I) - RADAR  PULSE  REPETITION  FREQUENCY  iPPS) 

r  RPRF 

258 

V  REAL  RADAR.PULSE.WIDTHd) - RADAR  PULSE  WIDTH  (MICRO'S) 

F  RPULSEWIDTH 

6.5 

V  REAL  RADAR.SWEEP.RATE  (I) - RADAR  ANTENNA  SWEEP  RATE  (RPM) 

e  RSWEEPRATE 

6 

V  REAL  RADARBEAMWIDTH(I) - RADAR  ANGULAR  BEAMWIDTH  (DEG) 

F  RBEAMWIDTH 

1.1 

V  REAL  RADAR _ANTENNA_GAIN(I) - MAXIMUM  RADAR  ANTENNA  GAIN  (DB) 

*  RANTENNAGAIN 
36 

V  REAL  RADAR.HAI.ALTII) - RADAR  MAX  HEIGHT  FINDING  ALTITUDE  (KM) 

c  RMAXALT 

20 

V  REAL  RADAR.TRANS.LCSS(I) - RADAR  TRANSMISSION  LOSS  FACTOR  (ND) 

c  R TRANSLOSS 

4 

V  REAL  RADAR .REC.LOSS(I) - RADAR  RECEPTION  LOSS  FACTOR (ND) 

c  RRECLOSS 

1 

V  RADAR.TYPE - EARLY  WARNING  (EW)  OR  ACQUISITION  (ACQ) 

c  rtype" 

EW 

V  INTEGER  RADAF._RE»DF:T_CYCLE . NUMEEF:  OF  SWEEPS  BETWEEN  REPORTS 

c  RREPORTCYCLE  * 

1 
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R  ROINIT 

V 

V  RADAR  SPECS 

V 

V  1=1 

V 

V  REAL  PO.CP.LAT (I) . RO_CP_LDNB (!) . R0_Cp_ALT ( I > 

c  ROLOCATION 

100E3.  1S2.5E3.  0 

V  INTEGER  RO_RADAR_SET ! I  i - RADAR  SET  TYPE  FOR  THE  RO  SITE 

r  RETYPE 

5 

V 

V  INTESER  N  MASK  ANGLE (I) - THE  NUMBER  OF  HASKINS  ANGLES  AT 

V  ’  *  - A  RADAR  SITE 

F  N'JNNASKANELES 

4 

V 

V  FOR  1=1.  N_HASK_ ANSLE ( I ) .  SPECIFV  THE  FOLLOWS 

V 

V  REAL  PSI  MASK (I . J ) . EPS  MASK ( I , J ) --THE  REFERENCE  AZIMUTHS,  ELEVATIONS 

V  *  FOR  HASKINS  AT  A  RADAR  SITE 

F  HASKAN5LES 

0,0 

90.0 

180.0 

27C.0 

V  INTESER  RO.STRUL 7URE ( I ) - STRUCTURE  TYPE  HOUSING  THE  CP 

e  ROSTRL'CT'JRE 

1 

V  INTEGER  NO.RO.SOII! - NUMBER  OF  SO  SUPERVISORS  FOR  RO!I) 

V  CAN  ONLY "HAVE  ONE  SUPERVISOR 

F  NOROSO 

1 

V  INTEGER  I.RO.SO(I.l) - INDEX  OF  THE  SO  SUPER  FOR  THIS  ROII) 

r  IROSO 

1 

V  REAL  FIRST.RO.SE.RVICEil) - FIRST  RO  SERVICE  TINE 

-  FRSTROSERVICE 

o.c 

V  REAL  CDNT.PO.EERVICEd) - CONTINUED  RO  SERVICE  TIME 

'  CONTROSERVICE  " 

0.0 

V  REAL  FUSION.RO.SERVICE(I) - FUSION  RO  SERVICE  TIME 

c  FUSNROSERVICE 

0.0 

R  S1INIT 

V 

V 

V  THIS  BLOCK  CONTAINS  THE  INITIAL  SI  SPECIFICATIONS 
TC 
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THIS  BLOCK  CONTAINS  THE  INITIAL  SI  SPECIFICATIONS 


FOR  1=1 . NUHS1  SPECIFY  THE  F0LL0WIN5 


1=1 


PEAL  Sl.CP.LAT (I), S! .CF.LONS II) . S! .CF  ALT!!! 

S1LOCATION 
1COEO.  100E3.  0 

INTESER  SI. STRUCTURE!! i - STRUCTURE  DESISNATION 

S1STRUCTURE  ' 

1 

INTESER:  NO.S1.S2'.!) . Nl'HBER  OF  SO  SUPERVISORS  FOR  SKI) 

S1S2 
NCSISC 
i 

INTESER  I _S1  _S2 ' 1 . 1  > - INITIAL  S2  SUPERVISORS  FOR  SKI) 

IS1S2 
1 

INTESER  NO.S1.CKI) - NUMBER:  OF  Cl  SUPERVISORS  FOR  SKI) 

i  SIC1 
NOS1C1 
0 

INTESER  I  SI  CKI.l) - INITIAL  Cl  SUPERVISORS  FOR  SKI) 

IS1C1 

REAL  FIRST  SI  SERVICE (I) - SERVICE  TIME  1  FDR  SI 

S1INIT 

FRSTS1 SERVICE 

1.0 

REAL  CONT  SI. SERVICE (I) - SERVICE  TIME  2  FOR  SI 

C0NTS1SERVICE 
0 

REAL  FUSI0N.S1. SERVICE! I) - SERVICE  TIME  3  FOR:  SI 

FU3NS1SERVICE 
0 

INTESER  Sl.SI.SE.EOKI' . SUBSTITUTE  PRIORITY 

S1S2SELECT 
0 

REAL  S1.S2  MULTIPLIER (I) - SUBSTITUTE  MULTIPLIER 

S1S2HULTIPLIER 


R  COINIT 

V 

V  FOR  I=1.NUMCC  PROVIDE  THE  FOLLOWING 

V 

V  1  =  1 

V 

V  INTEGER  COTYP(I) - CO  TYPE  DESIGNATION  (FI  OR  HI) 

c  COTYPE 

FI 

V  LOGICAL  CO  AUTO  (I! - CO  AUTO  CLASS  IDENTIFIER  (TRUE  FOR  AUTO) 

v  n:  autonomous  deration  allohed  for  caps 

F  COAUTO 

r 

V  REAL  CO_CP_LAT (I ) . CO_CP_LONG ( I > . CO_CP_ALT ( I ) 

V  IN  METERS! 111111 

F  COLOCATION 

20E3.  165E3,  0 

V  INTEGER  CO.STRUCTURE(I) - STRUCTURE  DESIGNATION 

COSTRUCTURE 
1 

INTEGER  CO.S.BCUND(I) - NUMBER  OF  6RID  POINTS  FORMING 

- THE  BOUNDARY  OF  CO 

C06B0UND 

4 

REAL  CO_LAT_BOUND(I,J) .CO  LONS  BOUND (I . J ) , J =1 . CO_G_BOUND ( I ) 

- LATITUDE  AND  LONGITUDE  POINTS  OF  THE  BOUNDARY 

IN  METERS' !!!'" 

COBOUNDARY 
15.  140E3 

1C1E3.  130E3 
110E3.  199E3 
15.  199E3 

REAL  CO_F_BOUND(I.3) - XO.YO.ZO  SPECIFICATIONS  FOR  A  PARABOLOID 

COINIT 
COFBO'JND 
0.0.0 

INTEGER  NO.CO.Cl II) - NUMBER  OF  Cl  SUPERVISORS  FDR  CO(I) 

COCI 

noccc: 

Q 

INTEGER  I_CC_C1 (I. 1) - INITIAL  Cl  SUPERVISORS  FOR  CO!I) 

INDEX  OF  C!  SUPERVISOR 
ICCC1 

INTEGER  N0.C0.C2d) - NUMEER  OF  C2  SUPERVISORS  FDR  CO(I) 

C0"2 
N0C0C2 

4 

l 

INTEGER  I.C0.C21I, 1) - INITIAL  C2  SUPERVISORS  FOR  COII! 

IC0C2 
1 

REAL  FIRST.CO.SERVICEd) 


•SERVICE  TIME  1  FOR  CO 


-SERVICE  TIRE  3  rQF:  CO 


FP.STCOSERVICE 
60 

REAL  CONT  CO  SERVICE!!) - SERVICE  TIME  Z  FOR  CO 

33NTC0SERVICE  ' 

0.0 

REAL  FUS!ON_CO_SERV!CE ( I ) - SERVICE  TIRE  3  ^OF 

FUSNCOSERVICE 

0.0 

FOR  COTYF-FI.  SPECIFY  LOITER  LAT.L0N5.ALT,  BASE  NUMBER 
REAL  CO_LQI  TEF._LfiT.  CO_LOI  TEF:_LON= .  CO_LOITEF._ftLT 

LOITERROINT  ' 

S0E3,  I65E3.  5E! 

INTEGER  BASE.NUMEER 
SA3ENUMBER 
1 

1NTEEER  NUM_DF_SERVERS !  I ) - NUMBER  OF  CO  SERVERS 

NUMOFSERVERS  ’ 


NUMBER  OF  SIMULTANEOUS  INTERCEPTS  BY  SC!  CONTROLLER 


INTEGER  N.UNIT.TYPES(I) - NUMBER  OF  UNIT  TYPES 

NUMBER  OF'dIFFERENT  TYPES  OF  FI  AS  DEFINED  IN  MEPARA 
NUNITYPES 
1 


FOR  EACH  UNIT  TYPE  PROVIDE  THE  FOLLOWING  FOR  3=1. N  UNIT  TYPES 
3  IS  THE  INDEX  FOR  THE  FIGHTER  TYPE 
3=1 


INTEGER  N_INIT_UNIT5(I.J) - INITIAL  NUMBER  OF  UNITS  BY  TYPE 

NUMBER  OF  FLIGHTS  OF  THIS  TYPE 
FIUNIT 
NUM'JNITS 
10 

INTEGER  CO.UNlT.TYPESd. 3)—  SPECIFIC  CO  UNIT  TYPES 
COUNITS 
1 

THIS  IS  THE  INDEX  OF  THE  FI  TYPE  FROM  THE  WEpARA  FILE 


FOR  Y=!.NJNITJJN!TSC.J)  SPECIFY  THE  FOLLOWING: 

K  IS  THE  INDEX  C0F.  THE  TOTAL  NO.  OF  FIGHTER  TYPE  3 

INTEGER  INIT.WEAPONS.UNITII, 3. K) - INITIAL  NUMBER  OF  WEAPONS  PER  UNIT 

NUMBER  OF  AIRCRAFT  PER  FLIGHT 
INITNEAPQNS 

VI  M  M  *  M  <)  M 


FOR  COTYP ( I ) =FI  SPECIFY  THE  FOLLOWING: 


INTEGER  INIT  CDNTU.3.K)- 


-INITIAL  UNIT  CONTROL  POLICIES 

- FOUR  LETTER  LITERALS 

—FORMATTED:  A001 . AOOC, . . . , AO  10 
- 10  MAXIMUM  PER  LINE 
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‘V.1  _v ;  . y  * -r  ‘ '  V  V 


OTONw^O'O  o' 


F  IN!TCOfr 

LCDS. LCDS. LODE, LOOS, LOOS. LOOS. LOOS. LOOS, LOOS, LOOS 

V 

V  ONE  ENTRV  REQUIRED  FOR  EACH  FLI5HT  OF  FI(J) 

V 

V  INTEGER  INI!  UNIT  ETATII.J.K) - INITIAL  UNIT  STATUS 

V  "  "  f 'REAS’  .  ’LOIT’  .  ’BASE’) 

F  IN!TUNITSTA' 

LOTT. LOIT. LOIT, LOIT, LOIT, LOIT, LOIT, LOIT, LOIT, LOIT 


.if  rz  cri  r 


FOP.  1=1 ,  NL'HCO  PROVIDE  THE  FOLLOHINE 


1=4 

INTEGER  COTYP ! I ) . CO  TYPE  DEE IBNATI ON  (FI  OF  HI) 

COTYPE 

HI 

LOGICAL  CO  AUTO! I) . . -CO  AUTO  CLASS  IDENTIFIER  (TRUE  FOR  AL'TOi 


AL'TONOHO'JS  OPERATION  ALLOWED  (TRUE/FALSE) 
COAL'TD 


REAI.  CO.CR.LAT ! I ) . CO.CF .LONS ! I ) , CO.CF.ALT ( I ! 

IN  HETERS1""!! 

COLOCATION 
160E3,  165E3.  0 

INTEEEF:  CO.ETRUCTURE(I) . STRUCTURE  DESIGNATION 

COSTRUCTURE 

1 

INTEEEF:  CO.B.BOUND(I) - NUHBER.  Oc  GRID  POINTS  FORMING 

- THE  BOUNDARY  OF  CO 

COEBOUND 

4 

REAL  CC.LAT  BOUND ( I , J ) ,  CO.LONE.BOUND ( I , J ) , J=1 , CO.B.BOUND ! I ) 

- LATUUDE  AND  L0N5ITUDE  POINTS  OF  THE  BOUNDARY 

IN  HETERS1!!'!!! 

COBOUNDARY 
120E3.145E3 
I99E3.135E3 
199E3.199E3 
110E3, 199E3 

REAL  CC_F_BOUND (1.3) - XO,YO.ZO  SPECIFICATIONS  FOR  A  PARABOLOID 

COINIT 
COFPQUND 
30E3.30E3. 100 

INTEGER  N0.C0.C1 (I) - NUHBER  OF  Cl  SUPERVISORS  FOR  CO(I) 

CAN  ONLY  HAVE  ONE  SUPERVISOR 

r  at  « 
u  *.  -  . 

NOCC’Cl 

I 

INTEGER  I.C0.C1 (1,1) . INITIAL  Cl  SUPERVISORS  FOR  COII) 

INDEX  OF  ACTUAL  Cl  SUPERVISOR 
IC0C1 
1 

INTEGER  NO  CO  CC!I) . NUHBER  OF  C2  SUPERVISORS  FOR  CO(I) 

C0C2 

N0C0C2 

0 

INTEGER  I.C0.C2(M) - INITIAL  C2  SUPERVISORS  FOR  00(1) 

CAN  ONLY  HAVE  A  Cl  OF:  A  C2  SUPERVISOR 


REAL  FIRST_CO_SERVICE ( I > - SERVICE  TIME  1  FOR  CO 

COINIT 

FRSTCOSERVICE 

0.0 

REAL  CONT.CO.SERVICE(I) - SERVICE  TIME  2  FOR  CO 

CONTCOSERVICE 

0.0 

REAL  FUSION_CO_SERVICE ( I ) - SERVICE  TIME  3  FOR  CO 

FU3NC0SERV ICE 

0.0 

FOF:  COTYRsFI.  SPECIFY  LOITER  LAT. LONS. ALT.  BASE  NUMBER 

REAL  C0_LDITER_LAT,C0_L0ITER_L0N5,C0_L0ITER.ALT 

LOITERPOINT 

INTEGER  BASE.NUMBER 

BASENUHBER 

INTEGER  NUM.OF.SERVERSd) - NUMBER  OF  CO  SERVERS 

NUMBER  OF  FIRE  CONTROLLERS  AVAILABLE 
NL'MOFSERVERS 
3 

INTEGER  N.UHIT.TYPES(I) - NUMBER  OF  UNIT  TYPES 

NUNITYPES 


FOR  EACH  UNIT  TYPE  PROVIDE  THE  FOLLOWING  FOR  J=1 , N_UNIT_TYPES 
Js! 

INTEEER  N  INIT  UNITSd, J> - INITIAL  NUMBER  OF  UNITS  BY  TYPE 

FISTUFF 

NUMUNITS 

0 

INDEX  OF  CO  UNIT  TYPE 
COUNITS 
1 

INITWEAPONS 

INITCONT 

IN!TUN!TETAT 

j=: 

INTEEER  N.INIT  UNITSd. J) - INITIAL  NUMBER  OF  UNITS  BY  TYPE 

NUMUNITS 

h 

INTEGER  CO.UNIT.TYPES ( I, J)—  SPECIFIC  CO  UNIT  TYPES 

COUNITS 

n 

THIS  IS  THE  INDEX  CORRESPONDING  TO  THE  HEPARA  FILE 
FOR  K=1.NJNIT_UNITS(I,J>  SPECIFY  THE  FOLLOWING: 


.It' kM  .1  j  Jf. 


I  **4  m-A  rj  ^  i 4  ta  ; 


PATHSI 


PATHS!  CONTAINS  PATH  DATA 


FOP  1=1. NPATHSI  INPUT  THE  FOLLONINE 


INTEBEP  N_PCINTSI (N_PATH_MAX ) -THE  NUMBER  OF  POINTS  ALONS  EACH  PATH 
NPOINTSI  ' 


FOR  J=1 . N_PDINTSI  SPECIFY  THE  FOLLOWING 

REAL  PATH  LAT ! I . 3 ) , PATH.L0N6 ! I , J ) , PATH_ALT ( I ,  J! 
IPOINTSI 

499E3.  190E3.  90 
120E3,  I90E3.  90 
5,  I90E3.  90 


INTE6ER  N  POINTSI (N_PATH_MAX > -THE  NUMBER  OF  POINTS  ALONE  EACH  PATH 
NPOINTSI 


FOR  3*1. N  POINTSI  SPECIFY  THE  FOLLOWING 


REA'BL  PATH.LAT  (I.  J) ,  PATHL0N5  (1,3),  PATH.  ALT  (1,3) 
IPOINTSI 

500E3,  145E3,  90 
95E3,  I45E3,  90 
S  ,  145E3,  90 


INTESER  N.PGINTSI  (N.PATH.HAD-THE  NUMBER  OF  POINTS  ALONE  EACH  PATH 
NPOINTSI  ' 


FOR  3=1,N.P0INTSI  SPECIFY  THE  FOLLOWING 

REAL  PATH.LAT (1,3), PATH.LONE (1,3). PATH. ALT (1.3) 

IPOINTSI 

502E3.  137E3,  90 
105E3,  137E3.  90 
5  ,  137E3.  90 
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INTE6ER  N_POINTSI (N_PATH_MAX ) -THE  NUHBER  OF  POINTS  ALONG  EACH  PATH 
NPOINTSI 

3 

FOP.  J = 1 , N_PO I NTSI  SPECIFY  THE  FOLLOWING 

REAL  PATH.LAT ( I . J ) , PATH_L0N6 ( I . J ) , PATH. ALT ( I . 3 ) 

IPOINTSI 

501E3.  105E3.  90 
110E3,  105E3,  90 
5  ,  105E3,  90 

1=5 

INTEGER  N_POINTSI (N_PATH_HAX ) -THE  NUHBER  OF  POINTS  ALONG  EACH  PATH 
NPOINTSI 


FOR  0=1, N  PDINT5I  SPECIFY  THE  FOLLOWING 

REAL  PATH  LAT (I , J ) , PATH .LONG (I, J) , PATH. ALT II, J) 

IPOINTSI 
499E3.  95E3,  90 
I15E3.  95E3,  90 
5  ,  95E3,  90 

1=6 

INTEGER  N.POINTSI  (N.PATH.HAD-THE  NUHBER  OF  POINTS  ALONG  EACH  PATH 
NPOINTSI 

3 

FOR  J=l. N.POINTSI  SPECIFY  THE  FOLLOWING 

REAL  PATH.LAT ! I , J ) , PATH.L0N6 ( I , J ) , PATH. ALT ( I , J  > 

IPOINTSI 
500E3.  60E3,  90 
120E3,  60E3,  90 
5  ,  60E3,  90 

1=7 

INTEGER  N.POINTSI (N.PATH  HAD -THE  NUHBER  OF  POINTS  ALONG  EACH  PATH 
NPOINTSI 


FOP.  Jsl.N.POINTSI  SPECIFY  THE  FOLLOWING 

REAL  PATH _L AT ( I . J ) . PATH.LDNB ( I . J ) . PATH. ALT  1 1 . J ) 

IPQINTSI 
496E3.  53E3.  90 
130E3,  53E3.  90 
5  ,  53E3,  90 

I»B 

INTESEP  N_PO!NTSI (N_PATH_NAX ) -THE  NUMBER  OF  POI..  .  ALONG  EACH  PATH 
NPQINTSI 

3 


FOP'A  J=1.N_P0INTSI  SPECIFY  THE  FOLLOWING 

REAL  PATH_LAT ! I . J ) , PATH  LONG ( I, J ) , PATH  ALTU.J) 
IPQINTSI 
501E3,  10E3,  90 
100E3,  10E3.  90 
5  ,  10E3,  90 


END  OF  FILE 


PENS  I 

FOP.  I=1.NUM_PEN_TYPES,  SPECIFY  THE  FOLLOHINE 


1=1  BQMBER/FI6HTER  BOMBER 

INTE5EF.  PEN.TYPES(I) - THE  SPECIFIC  PENETRATOR  TYPES 

PEN.TYPE 

1 

REAL  PEN  SPEED!!) - THE  PENETRATOR  SPEED 

PENSPEED 

260 

REAL  PEN.CROSS'.I! - THE  PENETRATOR  RADAR  CROSS -SECT  I  ON 

PENCR03S 

50 

INTE6ER  PEN.B0HBSII.3) - THE  NUMBER  OF  BOMBS  OF  EACH  TYPE 

CARRIED  BY  THE  PENETRATORS 

PENSOMBS 

A.e.c.c.o 

REAL  ECH.PONERtI.2) - THE  ECM  POWER  FOR  TWO  TYPES  OF 

TRANSMITTERS  (MATTS/MHZ) 

ECMPOWEF: 

0.0 


I=:  FIEHTER/FI6HTER  ESCORT 

INTE6EP  PEN  TYPES (I) - THE  SPECIFIC  PENETRATOR  TYPES 

PEN.TYPE 

REAL  PEN  SPEED  (I ) - THE  PENETRATOR  SPEED 

PENSPEED 

260 

REAL  PEN  CROSS  (I) - THE  PENETRATOR  RADAR  CROSS-SECTION 

PENCR03S 

10 

INTESER  PEN_80NBS(I,5) - THE  NUMBER  OF  BOMBS  OF  EACH  TYPE 

CARRIED  BY  THE  PENETRATORS 

PENBOHBS 

4, 8, 0,0,0 

REAL  ECM_PDWER!I,2) - THE  ECM  POWER:  FOR  TWO  TYPES  OF 

TRANSMITTERS  (WATTS/MHZ) 

ECMPOWEF; 

0,0 


vji»j  sar»jr« rmrm.-^  mrwrr ** ™vw»w™ 
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V 
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V 

V 

V 

V 

V 

V 
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BLOCK  ’PEN!!"’  CONTAINS  PENETR:ATOR  ARRIVAL  TINE  INPUTS 
INPUTS  TO  THE  SYSTEM  ARE  DESCRIBED  IN  TERNS  0r  PULSES  ALONG 
A  GIVEN  PENETRATION  PATH.  EACH  PULSE  IS  CHARACTERIZED  BY 
FIVE  PARAMETERS.  AS  SHOWN  BELOW. 


I- 


/ 1 
/  : 


/ 


/ 


LAMBDA  INIT 


\ 


A  ! - TAU.C.INIT - 1  A  ! 

I  I 

I  I 

! — TAU_F:_  INIT  TAU_F_INIT — ! 

- T_PULSES.INI!  ( the  initial  tiee  oP  the  Dulse) 


THE  NUMBER  OF  PENETRATORS  FOUND  IN  A  GIVEN  PULSE  WILL  BE 
LAMBDA  INIT  I  (TA'J  F.  INIT/C  ♦  TAU  C  INIT  +  TAU  F  INIT/2). 


INTEGER  N_P.AID_PATHS - THE  NUMBER  OF  PATHS  USED  FOR  RAIDS 

N  RAID  PATHS 
B 

FOP.  1=1. N_RAID_PATHS ,  SPECIFY  THE  FOLLOWING: 

1=1 

INTEGER  RAID.PATHS'.I) - THE  PATH  USED  FOR  THE  RAID 

PENTINSEQ 

RAIDPATHS 

1 

INTEGER  N_P_TYPES(I) - THE  NUMBER  OF  PENETRATOR  TYPES  USED 

NFTYPES 

1 

PATHBEN 

FOR  J=1 , N_P_TYPES,  S°ECIFY  THE  FOLLOWING: 

PTYPES 

J=1 

INTEGER  RETYPES! I. J) - THE  PENETRATOR  TYPE  USED 

1 

INTEGER  N_P'JLEE_INIT (I . J ) . THE  NUMBER  OF  ARRIVAL  PULSES 

NPULSEINIT 

10 
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F0E  K=1.N_PULSE_INIT,  SPECIFY  THE  FDLLDKINS: 

K=1 

PULSE 

REAL  LAMBDA_INIT (I . J. K! - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TA'J.P  INITII.J.K) - THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAL1  C  INITII.J.K) - THE  SECOND  PULSE  PHASE  VALUE 

3 

REAL  TAU_F_INIT  ( I ,  J .  K) - THE  LAST  PULSE  PHASE  VALUE 

0 

REAL  T_PULSES_INITII,J.K) - THE  START  TIKE  OF  THE  PULSE 

0 

K=2 

PULSE 

REAL  LAMBDA  JNIT I  l.J.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TAU  R  INITII.J.K! - THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAU  C  INITII.J.K) - THE  SECOND  PULSE  PHASE  VALUE 

3 

REAL  TAU  F  INITd.J.K) - THE  LAST  PULSE  PHASE  VALUE 

0 

REAL  T  PULSES  INIT(I,J,K) - THE  START  TIKE  OF  THE  PULSE 

15 

K=3 

PULSE 

REAL  LAMBDA  JNIT  1 1,  J.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

3.5 

REAL  TAUJRJNITII.J.K) - THE  FIRST  PULSE  PHASE  VALUE 

3 

REAL  TAU_CJNIT(I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

3 

REAL  TAU_FJNIT(I,  J.K) - THE  LAST  PULSE  PHASE  VALUE 

3 

REAL  T  PULSES  INITd, J,K) - THE  START  TIME  OF  THE  PULSE 

SO 


1=4 

>ULSE 

REAL  LAMBDA  INITII.J.K) 
).5 
REAL 


•THE  DISTRIBUTION  FUNCTION  VALUE 


TAU.RJNIT(I.J.K) 


•THE  FIRST  PULSE  PHASE  VALUE 


REAL  LAKBDA.!NITII,:.K> - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TAU.F_INr;i.J.K) . THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TALI  C  INrd.J.K! . THE  SECOND  PULSE  PHASE  VALUE 

3 

F.EAL  TAL'_f  THE  LAST  PULSE  PHASE  VALUE 

0 

PEAL  T_t,JLSES_!N!T 1 1 ,  J, K) . THE  START  TIME  OF  THE  PULSE 

105 


K=9 

PULSE 

REAL  LAMBDA_ INIT ( I , j , K) — 

0.5 

REAL  TAU  R  INITd, J.K!  — 

0 

REAL  TAU.C  ZNITCI.J.K) — 

B 

REAL  TAU  F  INI! (I, J.K) — 

0 

REAL  T  P'JLSES.INITd.J.K! 

ICO 


KdO 

PULSE 

REAL  LAHBDAJNIT'.I,  J,K!  — 

0.5 

REAL  TAU_P_INITd,J,K)  — 

0 

REAL  TAU  C  INITd. J.K)  — 

3 

REAL  TAU  r_INIT tl.J.K!  — 

0 

REAL  T  PULSES  INITd. J.K) 
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FOR  1*1 . N_RAID_PATH5,  SPECIFY  THE  FOLLOWING: 
I=C 


•THE  DISTRIBUTION  FUNCTION  VALUE 
•THE  FIRST  PULSE  PHASE  VALUE 
•THE  SECOND  PULSE  PHASE  VALUE 
■THE  LAST  PULSE  PHASE  VALUE 
■THE  START  TINE  OF  THE  PULSE 


■THE  DISTRIBUTION  FUNCTION  VALUE 
■THE  FIRST  PULSE  PHASE  VALUE 
•THE  SECOND  *ULSE  PHASE  VALUE 
•THE  LAST  PULSE  PHASE  VALUE 
■THE  START  TIflE  OF  THE  PULSE 


INTE5EF:  RAID  PATHS  d! 


■THE  PATH  USED  FOR  THE  RAID 


PENTIHSEQ 

RAIDFATHE 


INTE5ER  N.P.TYPESd) - THE  NUttBEP  Of  PENETRATOR  TYPEE  USED 

NPTYCES 

1 

PATHPEN 

FOP  J=1 . N_P_TYF£Et  SPECIFY  THE  F0LLDKIN6: 

PTYC'ES 

J=1 

INTEEER  P.TYPESd.J) - THE  PENETRATOR  TYPE  USED 

L 

INTEGER  N  PULSE.INITd,  J) - THE  NUMBER  Of  ARRIVAL  PULSES 

NPULSEIKIT 

1C 

FOR  K=1.N_PULSE_INIT.  SPECIFY  THE  F0LL0WIN6: 

K=! 

PULSE 

REAL  LAHBDA.INITd.J.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TAU.R.INITd.J.K) - THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAU  C  INITd.J.K! - THE  SECOND  PULSE  PHASE  VALUE 

3 

REAL  TAU_F_INITd,J,K> - THE  LAST  PULSE  PHASE  VALUE 

0 

REAL  T.PULSES  INITd.J.K) - THE  START  TINE  OF  THE  PULSE 

0 

K< 

PULSE 

REAL  LAHEDA.INITd.J.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TAU  F.  INITd.J.K) - THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAU  C  INITd.J.K) - THE  SECOND  PULSE  PHASE  VALUE 

B 

REAL  TAU.R.INITd.J.K) - THE  LAST  PULSE  PHASE  VALUE 

0 

REAL  T.PULSES. INITd.J.K) - THE  START  TIME  OF  THE  PULSE 


LAHBDAJNITU.J.K! - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_F._INIT(I, J,K> - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT !!, J.K) . THE  SECOND  PULSE  PHASE  VALUE 

T INIT (I,j,IO . THE  LAST  PULSE  PHASE  VALUE 

T  ^LSE:  INI” II. J.K) . THE  START  TINE  OF  THE  PULSE 


LAHBDAJNIT!!,  J.K) . THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT!I, J.K! - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT!I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_ INIT ( I ,  J, K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES.INIT(I,J,K) - THE  START  TINE  OF  THE  PULSE 


LAMBDAINIT ( I , J , K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU.RJNIT!I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TA'J_C_INIT (I,J.K> - THE  SECOND  PULSE  PHASE  VALUE 

TAU.FJNIT(I.J.K) - THE  LAST  PULSE  PHASE  VALUE 

T  PULSES, INIT II. J.K) - THE  ST  ART  TINE  OF  THE  PULSE 


LAHBDAJNIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I,J,K) . THE  FIRST  PULSE  PHASE  VALUE 


TAU_C_INITU,  J.K) 


•THE  SECOND  PULSE  PHASE  VALUE 


■THE  LAST  PULSE  PHASE  VALUE 


V 

REAL 

TAU  c  INITd.J.K) - 

-—THE  LAST  PULSE  PHASE  VALUE 

0 

V 

REAL 

T_PULSES_ INIT ( I . J . K) — 

- THE  START  TIME  OF  THE  PULSE 

TC 

i  J 

V 

V 

V 

K=7 

V 

F 

PULSE 

V 

REAL 

A  c. 

LAMBD  A_  INITd.J.K) - 

- THE  DISTRIBUTION  FUNCTION  VALUE 

V 

REAL 

ft 

TAL'_F:_INITd,  J,K) - 

-—THE  FIRST  PULSE  PHASE  VALUE 

V 

REAL 

TAL'_C_INITd,  J,K) - 

- THE  SECOND  PULSE  PHASE  VALUE 

3 

V 

REAL 

T  AU_F_INIT d,  J.K) - 

- THE  LAST  PULSE  PHASE  VALUE 

0 

V 

REAL 

T.PULSES  INITd.J.K)  — 

- THE  START  TIME  OF  THE  PULSE 

V 

90 

V 

V 

K=9 

V 

F 

PULSE 

V 

REAL 

LAMBDA  INITd.J.K) - 

- THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

V 

REAL 

taujmnit  d,  j.k) - 

- THE  FIRST  PULSE  PHASE  VALUE 

0 

V 

REAL 

q 

TAU_C_INIT (I, J,K) - 

- THE  SECOND  PULSE  PHASE  VALUE 

V 

REAL 

TAU.F  INIT(I,J,K) - 

- THE  LAST  PULSE  PHASE  VALUE 

0 

V 

REAL 

T.PULSES  INITd.J.K)-- 

- THE  START  TIME  OF  THE  PULSE 

V 

105 

V 

V 

K=9 

V 

F 

PULSE 

V 

REAL 

r,  c 

LAMBDA.INITd.J.K! - 

-—THE  DISTRIBUTION  FUNCTION  VALUE 

V 

V  .  J 

REAL 

TAU.F:  INITd.J.K! - 

- THE  FIRST  PULSE  PHASE  VALUE 

0 

V 

REAL 

TAU.C. INITd.J.K) - 

-—THE  SECOND  PULSE  PHASE  VALUE 

3 

V 

REAL 

TAU.F. INITd.J.K) - 

-—THE  LAST  PULSE  PHASE  VALUE 

0 

V  REAL  T.PULSES  INITd.J.K) 
120 


V 

V 


■THE  START  TIME  OF  THE  PULSE 


V 
c 

V 

V 

V 

V 


V 


V 

V 

V 

V 

V 

V 

V 
F; 
F 

V 

V 
r 

V 
F. 

V 
c 

V 

n 

V 

V 

V 


V 

V 

V 


V 

V 

F 

V 

V 


V 

V 


PULSE 

REAL 

!"j  C 

LAKEDAJNITd.J.K) - 

-—THE  DISTRIBUTION  FUNCTION  VALUE 

REAL 

o 

TAU_R_INIT(It»\K)- . 

- THE  FIRST  PULSE  PHASE  VALUE 

REAL 

3 

REAL 

o 

TAU_C_INIT!I,J,K) . 

-—THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT (I.u.Ki - 

-—THE  LAST  PULSE  PHASE  VALUE 

REAL 
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T_PULSES_INIT!I,  J,K! — 

-—THE  START  TIME  OF  THE  PULSE 

FOR  1*1, 

, N_RAI D_PATHS,  SPECIFY  THE  FOLLOWING: 

1=3 


INTEGER  RAID.PATHS(I) . THE  PATH  USED  FDR  THE  RAID 

PENTIMSEG 
F:A  I  DEATHS 


INTEGER  N  P  TYPES! I) - THE  NUMBER  OF  PENETRATDR  TYPES  USED 

NCTYPES 

1 

PATHPEN 

FOR  J=l, N_P_TYPES,  SPECIFY  THE  F0LL0HIN5: 

F TYPES 

J*1 

INTEGER  RETYPES ( I, J! . THE  PENETRATDR  TYPE  USED 

1 

INTE6ER  N_PULSE  INITU.J) - THE  NUMBER  OF  ARRIVAL  PULSES 

NPULSEIMIT 

10 

FOR  K=1.N_FULEE_INIT.  SPECIFY  THE  FOLLOWING: 

K=1 

PULSE 

REAL  LABBDA.IHITIIJ.K) . THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TAU  R  INIT1IJ.K! . THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAU  C  INIT(I, J,K) . THE  SECOND  PULSE  PHASE  VALUE 

9 

REAL  TAU  F  INIT(I,J,K) . THE  LAST  PULSE  PHASE  VALUE 

0 


C-28 


T_PULSEB_INIT ( I . J, K) 


THE  START  TIME  OF  THE  PULSE 


LAHEDA_INIT!I.J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_F._INITH,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT!I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT  ( I ,  J , K> - THE  LAST  PULSE  PHASE  VALUE 

T_PULSEE_INIT (I, J,K) - THE  START  TIME  OF  THE  PULSE 


LAMBDA_INIT ( If J, K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT (I, J,K> - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT (I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT!I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT ( I , 3, K) - THE  START  TINE  OF  THE  PULSE 


LAMBDA_INIT ( I , J , K ) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAL'_P_!NIT(I.J,K) . THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT ( I,  J.K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT!I,J,K) - THE  START  TIHE  OF  THE  PULSE 


LAHBDAJNIT!I,J,K) 


THE  DISTRIBUTION  FUNCTION  VALUE 


TfiL'_F:_INIT(I. J.K) - THE  FIRST  PULSE  PHASE  VALUE 

TAL'_E_1NIT!!,2,K) - THE  SECOND  PULSE  PHASE  VALUE 

TA'._C_!NIT (I. JtK) . THE  LAST  PULSE  PHASE  VALUE 

\*‘JLSES_IKIT!i.J,K> - THE  START  TIKE  OF  THE  PULSE 


LANBOMNITCJ.K! - THE  DISTRIBUTION  FUNCTION  VALUE 

*AL_FJN!T!I.:.K> . THE  FIRST  PULSE  PHASE  VALUE 

TAL_C_INITC. J.K> - THE  SECOND  PULSE  PHASE  VALUE 

TAL'.F.INITdJ.K! - THE  LAST  PULSE  PHASE  VALUE 

T .PULSES. INIT!!,J,K> - THE  START  TINE  OF  THE  PULSE 


LAMBDAJNITIIJ.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_P_INIT ( I ,  J , K) - THE  FIRST  PULSE  PHASE  VALUE 

tau.cjnitii.j.k; - the  second  pulse  phase  value 

TAU_F_INIT  ( I ,  J ,  K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT (I, J,K) - THE  START  TINE  OF  THE  PULSE 


LAHBDA_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU  F  INIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 


REAL  T_PULSES_ INIT !  I , J ,  K) 

105 


K=9 

PULSE 

REAL  LAMBDA_  INIKI.J.K)  — 

C .  5 

REAL  TAU_F:_INIT(I.  J.K)  — 

0 

REAL  TAU_C_INIT (I,J,K) — 

3 

REAL  TAU_F_INIT(I, J.K) — 

0 

REAL  T_PL!LSEE_INIT  ( I ,  J ,  K) 

120 


K=10 

PULSE 

REAL  LAMBDA  INITd, J,K)~ 

0.5 

REAL  TAU_R_INIT(I, J,K) — 

0 

REAL  TAU  C  INITd, J.K) — 

S 

REAL  TAU  F  INITd, J,K)  — 

0 

REAL  T_PULSEE_INIT(I, J,K) 
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■THE  START  TIME  DF  THE  PULSE 


■THE  DISTRIBUTION  FUNCTION  VALUE 
■THE  FIRST  PULSE  PHASE  VALUE 
■THE  SECOND  PULSE  PHASE  VALUE 
•THE  LAST  PULSE  PHASE  VALUE 
■THE  START  TINE  OF  THE  PULSE 


■THE  DISTRIBUTION  FUNCTION  VALUE 
■THE  FIRST  PULSE  PHASE  VALUE 
■THE  SECOND  PULSE  PHASE  VALUE 
•THE  LAST  PULSE  PHASE  VALUE 
■THE  START  TINE  OF  THE  PULSE 


FOR  1=1 , N_RAIB_PATHS,  SPECIFY  THE  F0LLONIN6: 

1=4 

INTEGER  RAIE.PATHSdi - THE  PATH  USED  FOR  THE  RAID 

PENTINSEQ 

RAIDPATHS 

4 

INTE6ER  N.P.TYPESd) - THE  NUMBER  OF  PENETRATDR  TYPES  USED 

NPTYPES 

1 


PATHPEN 

FOR  J= 1 , N_P_TYPES,  SPECIFY  THE  FOLLOWING: 


THE  PENETRftTQF  TYPE  USED 


INTEGER  P  TYPES! I. JJ- 


INTE5ER  N .PULSE  IHITd.Jl- 
NPULSEINlf 
10 


-THE  NUMBER  OF  ARRIVAL  PULSES 


FOF  K=1 

.N.PULSE.INIT,  SPECIFY 

PULSE 

REAL 

LAMBDA_INIT(I, J,K) — 

0.5 

REAL 

TAU.R  INITtI, J,K) — 

0 

REAL 

TAU.C  INITtI, J,K) — 

a 

REAL 

TAU.F  INITtI, J,K)  — 

0 

REAL 

T.PULSES.INITtI, J,K) 

0 

K=2 

PULSE 

REAL 

LAMBDA_INIT (IfJ,K) — 

0.5 

REAL 

TAU_R_INIT(I, J,K) — 

0 

REAL 

TAU_C  INITtI, 3, K)--- 

B 

REAL 

TAU.F  INITtI, J.K) — 

0 

REAL 

T.PULSES.INITtI, J,K) 

15 

K=3 

PULSE 

REAL 

LAMBDA  INITtI, J,K)-- 

0.5 

REAL 

TAU.R.INITd,  J,Kt  — 

0 

REAL 

TAU.C.INITtI, J,K) — 

B 

REAL 

TAU_F_INIT ( 1 , J , K>  — 

0 

REAL 

T.PULSES. INITtI, J,K) 

-THE  DISTRIBUTION  FUNCTION  VALUE 
-THE  FIRST  PULSE  PHASE  VALUE 
-THE  SECOND  PULSE  PHASE  VALUE 
-THE  LAST  PULSE  PHASE  VALUE 


-THE  DISTRIBUTION  FUNCTION  VALUE 
-THE  FIRST  PULSE  PHASE  VALUE 
-THE  SECOND  PULSE  PHASE  VALUE 


-THE  DISTRIBUTION  FUNCTION  VALUE 
-THE  FIRST  PULSE  PHASE  VALUE 
-THE  SECOND  PULSE  PHASE  VALUE 
-THE  LAST  PULSE  PHASE  VALUE 


LAHBD A_ I N I T ( I , J , K ) 


THE  DISTRIBUTION  FUNCTION  VALUE 


V 

REAL 

A 

TAU_R_INIT(I,J,K) - 

-—THE  FIRST  PULSE  PHASE  VALUE 

V 

REAL 

0 

TAU.C.INIT(I,J,K) - 

-—THE  SECOND  PULSE  PHASE  VALUE 

V 

REAL 

A 

TAU_F_INIT(I,J,K) - 

- THE  LAST  PULSE  PHASE  VALUE 

V 

REAL 

T_PULSES_INIT(I,J,K) — 

— THE  START  TIHE  OF  THE  PULSE 

45 

V 

V 

V 

K=5 

V 

F 

PULSE 

V 

REAL 

LAHBDA_INIT(I,J,K) - 

- THE  DISTRIBUTION  FUNCTION  VALUE 

m 

V 

REAL 

A 

TAU_R_INIT(I,J,K) - 

-—THE  FIRST  PULSE  PHASE  VALUE 

V 

REAL 

p 

TAU_C_INIT(I,J,K) - 

— THE  SECOND  PULSE  PHASE  VALUE 

V 

REAL 

A 

TAU_F_INIT ( I , J, K) - 

— THE  LAST  PULSE  PHASE  VALUE 

V 

REAL 

T_PUL5EE_I NIT (I . J , K) - 

— THE  START  TIHE  OF  THE  PULSE 

V 

50 

V 

V 

K=6 

V 

F 

PULSE 

V 

REAL 

LAHBDAINITd,  J,K) - 

- THE  DISTRIBUTION  FUNCTION  VALUE 

V 

REAL 

TAU_R_INIT(I, J.K) - 

— THE  FIRST  PULSE  PHASE  VALUE 

V 

REAL 

p 

TAU_C_INIT ( I, J , K> - 

- THE  SECOND  PULSE  PHASE  VALUE 

V 

REAL 

A 

TAU.F.INIT(I,J,K) - 

- THE  LAST  PULSE  PHASE  VALUE 

V 

REAL 

T_PULSES_INIT!I, J,K) — 

- THE  START  TIHE  OF  THE  PULSE 

V 

75 

V 

V 

K-7 

V 

F 

PULSE 

LAMBDA_INIT ( I , J, K) 


THE  DISTRIBUTION  FUNCTION  VALUE 


TAUJMNIT(I,J,K> 

TAU_C_INIT(I,I],K) 


•THE  FIRST  PULSE  PHASE  VALUE 


•THE  SECOND  PULSE  PHASE  VALUE 

TA’J_FJNIT!1,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_ INIT 1 1 , J , K) - THE  START  TIME  OF  THE  PULSE 


LAMBDA_IN!T(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU.R_INIT(I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TA'J_C_IMIT ( I, J, K) - THE  SECOND  PULSE  PHASE  VALUE 

TAL'_F_INIT(I,J,K> - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES.INIT(I,J,K) - THE  START  TINE  OF  THE  PULSE 


LANBDA_INIT(I,J,K)~ 
TAU_R_INIT(I,  J,K)  — 
TAU.C.INITII,:,K)  — 
TAU.FJNIT(I,J,K)  — 
T_PULSES_INIT(I,J,K) 


•THE  DISTRIBUTION  FUNCTION  VALUE 
■THE  FIRST  PULSE  PHASE  VALUE 
■THE  SECOND  PULSE  PHASE  VALUE 
■THE  LAST  PULSE  PHASE  VALUE 
■THE  START  TINE  OF  THE  PULSE 


LANBDA_INIT(I,J,K)  — 
TAl!JUNIT(I,J,K)~ 
TAU_CJNIT(I,J,K)~ 
TAU.F_INIT(I,  J,K)  — 
T.PULSES.INIT(I,J,K) 


■THE  DISTRIBUTION  FUNCTION  VALUE 
•THE  FIRST  PULSE  PHASE  VALUE 
■THE  SECOND  PULSE  PHASE  VALUE 
■THE  LAST  PULSE  PHASE  VALUE 
•THE  START  TINE  OF  THE  PULSE 
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V 

V 

V  FOR  I=1,N_RAIB_PATHS,  SPECIFY  THE  FOLLOWING: 

V 

V  1=5 

V 

V  INTEGER  RAI DEATHS' I) . THE  PATH  USED  FOR  THE  RAID 

R  PENT  I USE Q 

F  RAIDPATHE 

.  5 

V 

V  INTEGER  N_P_TYPES  ( I ) . THE  NUMBER  OF  PENETRATOR  TYPES  USED 

r  NPTYPES 

1 

V 

R  PATHPEN 

V  FOR  J=1 . N_P_TYPES,  SPECIFY  THE  FOLLOWING: 

P  PTYPES 

V 

V  J=1 

V 

V  INTEGER  P_TYPES(I,J) - THE  PENETRATOR  TYPE  USED 

1 

V  INTEGER  N  PULSE  INITU, J) - THE  NUMBER  OF  ARRIVAL  PULSES 

F  NPULSEINIT 

10 

V 

V  FOF:  K=1,N_PULSE_INIT,  SPECIFY  THE  FOLLOWING: 

V 

V  K=1 

V 

F  PULSE 

V  REAL  LAMBDA_ INI T (I , J , K) - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

V  REAL  TAU_R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

0 

V  REAL  TAU_CJNIT(I,JfK> . THE  SECOND  PULSE  PHASE  VALUE 

*  S 

V  REAL  TAU_F_INIT(I. J.K) . -—THE  LAST  PULSE  PHASE  VA^UE 

0 

V  REAL  T_PULSES_I NIT ( I , J , K) . THE  START  TINE  OF  THE  PULSE 

0 

-  V 

V 


V 

V 

K=2 

F 

PULSE 

V 

REAL 

LAMBDAJNIT(I,J,K) - 

. THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

V 

REAL 

TAU_R_INIT ( I,  J,  K> - 

. THE  FIRST  PULSE  PHASE  VALUE 

0 


C-CT5 


•THE  SECOND  PULSE  PHASE  VALUE 


TAU_C_INIT  (1, 3,10 

TAU_F_IMIT (I, J,K> - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT ( I , J, K) . THE  START  TIME  DF  THE  PULSE 


LAMBDAJNITtl.J.K) . THE  DISTRIBUTION  FUNCTION  VALUE 

TAU.R.INITI 1,3,10 - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K> - THE  SECOND  PULSE  PHASE  VALUE 

TAL'_FJNIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T.PULSES.IN!T(I,J,K) - THE  START  TIME  OF  THE  PULSE 


LAMBDAJNIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INITtI, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT (I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PL)LSES_INIT { I , J , K) - THE  START  TIME  OF  THE  PULSE 


LAMBDA _INITtI. J,K)  -- 
TAUJMNITU.J.K)  — 
TAU_C_INIT(I,J,K>  — 
TAU_F_INIT ( I , J , K) — 
T  PULSES  INITII, J,K) 


■THE  DISTRIBUTION  FUNCTION  VALUE 
•THE  FIRST  PULSE  PHASE  VALUE 
•THE  SECOND  PULSE  PHASE  VALUE 
■THE  LAST  PULSE  PHASE  VALUE 
THE  START  TIME  OF  THE  PULSE 


LAHBDA_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAUJJNITdJ.K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT(I, J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT!I, J,K) - THE  START  TIME  OF  THE  PULSE 

LAHBDA_INIT(I, J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAL'_F_INIT(I, J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_I NIT ( I , J , K) - THE  START  TIHE  OF  THE  PULSE 

LANBDAINIT ( I , J, K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INITU, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAL'_F_IN!T(I, J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT ( I, J, K) - THE  START  TIME  OF  THE  PULSE 


LAHBDA_INIT!I,J,K> 


THE  DISTRIBUTION  FUNCTION  VALUE 


V 

REAL 

0 

TAL!_C_INIT!I,J,K) - 

-—THE  SECOND  PULSE  PHASE  VALUE 

V 

REAL 

A 

TAU_F_INIT  1 1,  J, K) - 

-—THE  LAST  PULSE  PHASE  VALUE 

V 

REAL 

T_PULSES_INIT(I.J,K1 — 

- THE  START  TIME  OF  THE  PULSE 

V 

V 

120 

V 

V 

K=10 

F 

PULSE 

V 

REAL 

LAHBDA.INITII, J,K) - 

- THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

V 

REAL 

tau.r.initii, J,K) - 

- THE  FIRST  PULSE  PHASE  VALUE 

V 

0 

REAL 

TAU_C_INIT(I,J,K) - 

- THE  SECOND  PULSE  PHASE  VALUE 

V 

□ 

REAL 

TAU_F_INIT ( I,  J , K) - 

- THE  LAST  PULSE  PHASE  VALUE 

V 

u 

REAL 

T  PULSES JNIT(I,J,K)  — 

- THE  START  TIME  OF  THE  PULSE 
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4 

V 

V 

V  FOR  I=1,N_RAID_PATHS,  SPECIFY  THE  FOLLOWING: 

V 

V  l=b 

V 

V  INTEGER  RAID.PATHS(I) - THE  PATH  USED  FOR  THE  RAID 

R  PENTIHSEQ 

F  RAIDPATHS 

6 

V 

V  INTE6ER  N.P.TYPES(I) - THE  NUMBER  OF  PENETRATOR  TYPES  USED 

F  NPTYPES 

1 

V 

R  PATHPEN 

V  FOR  J=1 , N_P_TYPES,  SPECIFY  THE  FOLLOWING: 

c  PTYPES 

V 

V  J=1 

V 

V  INTEGER  P_TYPES!I, J) - THE  PENETRATOR  TYPE  USED 

1 

V  INTEGER  N_PULSE_INIT(I, J) - THE  NUMBER  OF  ARRIVAL  PULSES 

c  NPULSEINIT 

10 

V 


FOR  K=1,N_PULSE_INIT,  SPECIFY  THE  FOLLOWING: 


LAHBDAJNITU,J,K> - THE  DISTRIBUTION  FUNCTION  VALUE 

TAUJ:JNIT(I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU.C_INIT(I,J,K> - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_  IN  IT !  I ,  J ,  K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_IMIT (I, J.K) - THE  START  TIME  OF  THE  PULSE 


LAMBDA_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT(I, J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT ( I , J , K) - THE  START  TIME  OF  THE  PULSE 


LAH8DA_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I, J.K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT(I, J.K) - THE  START  TIME  OF  THE  PULSE 


LAHBDA_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

T AU_R_INIT ( I, J , K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INITU, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU.F_INIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 


T_PULSES_INIT!I.JtK) - THE  START  TIME  OF  THE  PULSE 


LAHBDfi_ I NI T ( I , J , K! . THE  DISTRIBUTION  FUNCTION  VALUE 

TAL'JMNIT'U.K) . THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K) . THE  SECOND  PULSE  PHASE  VALUE 

TAU.F.INITtl, J.K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT ( I , J , K) - THE  START  TIME  OF  THE  PULSE 


LAHBDA_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT ( I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT (I, J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSE5_INIT ( I , J , K) - THE  START  TIME  OF  THE  PULSE 


LAKBBA_ INIT(I.J.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT (I,J,K) - THE  LAST  PULSE  PHASE  VALUE 


T_PULSES_INIT (I.J,K) 


THE  START  TINE  OF  THE  PULSE 


REAL  LAHEDAJNIT(IJ.K) 

0.5 

REAL  TAl'_R_INIT(I,J.K>- 

0 

REAL  T A!J_C  INITCI.J.K)- 

8 

REAL  TAU  F  IN!T!I,J,K!- 

0 

REAL  T  PULSES  INIT!!.J,K> 

105 


K=9 

PULSE 

REAL  LAMBDA_INIT(I,J,K) 

0.5 

REAL  TAU_R_IN1T ( 1 , J , K) - 

0 

REAL  TAU_C_INIT(1,J,K)- 

3 

REAL  TAUF1NIT (I,J,K>- 

0 

REAL  T_PULSES_INIT(I, J,K) 

120 


K-10 
PULSE 

REAL  LAMBDA  INIT(I,J,K)~ 

0.5 

REAL  TAU  R  INITII, J,K) — 

0 

REAL  TflU_C_INIT(I, J,K> — 

8 

REAL  TAU_F_INIT(I,J,K) — 

0 

REAL  T_P‘JLSES_IN!T  ( I ,  J,  K! 
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•THE  DISTRIBUTION  FUNCTION  VALUE 
THE  FIRST  PULSE  PHASE  VALUE 
THE  SECOND  PULSE  PHASE  VALUE 
THE  LAST  PULSE  PHASE  VALUE 
THE  START  TIME  OF  THE  PULSE 


THE  DISTRIBUTION  FUNCTION  VALUE 
THE  FIRST  PULSE  PHASE  VALUE 
THE  SECOND  PULSE  PHASE  VALUE 
THE  LAST  PULSE  PHASE  VALUE 
THE  START  TIME  OF  THE  PULSE 


THE  DISTRIBUTION  FUNCTION  VALUE 
THE  FIRST  PULSE  PHASE  VALUE 
THE  SECOND  PULSE  PHASE  VALUE 
THE  LAST  PULSE  PHASE  VALUE 


THE  START  TIME  OF  THE  PULSE 

FOR  1=1, N_RAID_PATHS,  SPECIFY  THE  FOLLOHIN6: 

1=7 


INTE6EP  RAID.PATHS(I) 

PENTIHSE8 

RAIDPATHS 


■THE  PATH  USED  FOR  THE  RAID 


V  INTE5EF:  M_P_TVPES (I) . THE  NUMBER  OF  PENETRATGR  TYREE  USED 

F  NP'YPE3 

1 

V 

R  PATHPEN 

V  FOR  J=!.N_P_TYPES,  SPECIFY  THE  FOLLOWINE: 

'  PTYPES 

V 

V  J=1 

y 

V  IKTEEER  P.TYPESd.J) . THE  PENETRATBR  TYPE  USED 

1 

V  INTE5ER  N_PULSE_IN!T ( I , J ) - THE  NUMBER  OF  ARRIVAL  PULSES 

c  NPULSEINIT 

10 

V 

V  FOR  K=1 , N_PULSE_INIT,  SPECIFY  THE  FOLLOWINE: 

V 


K=1 

PULSE 

REAL 

f)  c, 

LAMBDA.INITd, J.K) - 

-—THE  DISTRIBUTION  FUNCTION  VALUE 

v  ■  J 

REAL 

TAU.R.INIT(I,J,K! - 

—-THE  FIRST  PULSE  PHASE  VALUE 

u 

REAL 

3 

REAL 

rt 

TAU.C_INIT(I,J,K) - 

-—THE  SECOND  PULSE  PHASE  VALUE 

TAU.F.INITd,  J,K) - 

- THE  LAST  PULSE  PHASE  VALUE 

REAL 

0 

T.PULSES.INITII, J,K) — 

-—THE  START  TIME  OF  THE  PULSE 

V 

V 

V  K=2 

V 

F  PULSE 

V  REAL 
0.5 

V  REAL 

V 

V  REAL 
8 

V  REAL 
0 

V  REAL 
15 

V 

V  K*3 

V 

F  PULSE 

V  REAL 
0,5 


LAMBDA.INITd, J.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU.RJNITd.J.K) . THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K) . THE  SECOND  PULSE  PHASE  VALUE 

TAU.F.INITd,  J,K) - THE  LAST  PULSE  PHASE  VALUE 

T.PULSES_INITd,J,K) - THE  START  TIME  OF  THE  PULSE 


LAMBDA.INITII, J,K) . THE  DISTRIBUTION  FUNCTION  VALUE 


C-42 


0 


TAUJUNITd.J.K) 


THE  FIRST  PULSE  PHASE  VALUE 


V  REAL  TAU  C  INITd, J,K) - THE 

8 

V  REAL  TAL’_F_INIT{I,JtK> - THE 

0 

V  REAL  T.PULSES.INITUJ.K) . THE 


30 

V 

V 

V  K=4 

V 

F  PULSE 


V  REAL  LAMBDA  INITfl, J,K) - THE 

0.5 

V  REAL  TAU  R  INITd, J,K) - THE 

0 

V  REAL  TAU  C  INITd, <3, K) - THE 

8 

V  REAL  TAU  F  INITd. J,K) - THE 

0 


V  REAL  T.PULSES  INITd, J,K) THE 

45 

V 

V 

V  K=5 

V 

F  PULSE 


V  REAL  LAHBDA.INITd.J.K) - THE 

0.5 

V  REAL  TAUJMNITd.JJ) . THE 

0 

V  REAL  TAU  CJN!Td,J,K) - THE 

8 

V  REAL  TAU_F_INITt!,3,K) - THE 

0 

V  REAL  T_PULSES_INIT  (I ,  J ,  K) - THE 


60 

V 

V 

V  K=6 

V 

F  PULSE 


V  REAL  LAHBDA_INITd,J,K) - THE 

0.5 

V  REAL  TAU_R_INIT(I,  J,K> . THE 

0 

V  REAL  TAU  C  INITd, J,K) - THE 

8 

V  REAL  TAU_F_INIT(I,  J,K) - THE 

0 


SECOND  PULSE  PHASE  VALUE 
LAST  PULSE  PHASE  VALUE 
START  TIME  OF  THE  PULSE 


DISTRIBUTION  FUNCTION  VALUE 
FIRST  PULSE  PHASE  VALUE 
SECOND  PULSE  PHASE  VALUE 
LAST  PULSE  PHASE  VALUE 
START  TIME  OF  THE  PULSE 


DISTRIBUTION  FUNCTION  VALUE 
FIRST  PULSE  PHASE  VALUE 
SECOND  PULSE  PHASE  VALUE 
LAST  PULSE  PHASE  VALUE 
START  TIME  OF  THE  PULSE 


DISTRIBUTION  FUNCTION  VALUE 
FIRST  PULSE  PHASE  VALUE 
SECOND  PULSE  PHASE  VALUE 
LAST  PULSE  PHASE  VALUE 


T_PULSES_INIT  CI.J,K) 


■THE  START  TIME  OF  THE  PULSE 


LAHBDA_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(1, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT  (I,  J.K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT (I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT(I,J,K) - THE  START  TIME  OF  THE  PULSE 


LANBDA_INIT(I,J,K> - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_IN!T(I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT!I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT ( I , 3 , K) - THE  START  TIME  OF  THE  PULSE 


LAMBDAINIT (I , J , K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TA'J_F_INIT(I, J.K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT (I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU.F_INIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT < I , J , K) - THE  START  TINE  OF  THE  PULSE 


LAHBDA_INIT ( I , J, K) 


THE  DISTRIBUTION  FUNCTION  VALUE 


0.5 

REAL  TAU  R  INIKI, J.K) - THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAU  C  INITd, J.K) - THE  SECOND  PULSE  PHASE  VALUE 

3 

REAL  TAU  f  INITd, J.K) - THE  LAST  PULSE  PHASE  VALUE 

0 

REAL  T_PULSES_INIT(I, J,K) - THE  START  TINE  OF  THE  PULSE 

!35 


FOF;  1=1.  N_RAID_PATH5,  SPECIFY  THE  FOLLOWING: 

1=8 

INTEGER  RAID  PATHS  (I! - THE  PATH  USED  FOR  THE  RAID 

PENTIMSEG 

RAIDPATHS 

B 

INTEGER  N  P  TYPES! I) - THE  NUMBER  OF  PENETRATOR  TYPES  USED 

NPTYPES 

1 

PATHPEN 

FOR  J=1 . N  P  TYPES,  SPECIFY  THE  FOLLOWING: 

FTYPES 

J=1 

INTEGER  P.TYPES(I,J) - THE  PENETRATOR  TYPE  USED 

1 

INTEGER  N.PULSE  INITd, J) - THE  NUMBER  OF  ARRIVAL  PULSES 

NPULSEINIT 

10 

FOR  K=1 , N_PULSE_I NIT,  SPECIFY  THE  FOLLOWING: 

K=! 

PULSE 

REAL  LAMBDA_INIT ( I , J, K) - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TAU_R_INIT(I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAU_C_INIT!I, J.K) - THE  SECOND  PULSE  PHASE  VALUE 

B 

REAL  TAU_F_INIT(I, J,K) - THE  LAST  PULSE  PHASE  VALUE 

0 

REAL  T_PULSES_ INIT ( I , J , K) - THE  START  TINE  OF  THE  PULSE 


LflHBDfl_INIT(I,J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU.C.JNITd,  J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_1N1TIU,K) - THE  LAST  PULSE  PHASE  VALUE 

T_P‘JLSES_INIT ( I . J . K) - THE  START  TIME  OF  THE  PULSE 


LAMBDA_INIT ( I , J , K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT ( I ,  J ,  K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT Cl, J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT(I,J,K) - THE  START  TIME  OF  THE  PULSE 


LAHBDAINIT ( I, J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT (I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU.FJNITtU.IO - THE  LAST  PULSE  PHASE  VALUE 

T.PULSES_INIT(IJ,K) - THE  START  TIME  OF  THE  PULSE 


LAMBDA.  INIT!IJ,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU.R.INITtI, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU.C.INIT(I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 


TAL'_F_INITtI,J.K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT(I,J,K) - THE  START  TIHE  OF  THE  PULSE 


LAHBDA_INIT (I, J.K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU.R_INIT(I, J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT (I, J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT ( I , J , K> - THE  START  TIHE  OF  THE  PULSE 


LAHBDA_INIT(I, J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT ( I,  J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT(I, J.K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT (I , J , K) - THE  START  TIHE  OF  THE  PULSE 


LAHBDA_INIT(I,J,K> - THE  DISTRIBUTION  FUNCTION  VALUE 

TAU_R_INIT(I,J,K) - THE  FIRST  PULSE  PHASE  VALUE 

TAU_C_INIT(I,J,K) - THE  SECOND  PULSE  PHASE  VALUE 

TAU_F_INIT(I,J,K) - THE  LAST  PULSE  PHASE  VALUE 

T_PULSES_INIT!I,J,K) - THE  START  TIHE  OF  THE  PULSE 


PULSE 

REAL  LAMBDA  INITd,  J.K) - THE 

0.5 

REAL  TAU_F'_INITd,J.K) - THE 

0 

REAL  TA'J  C  INITU, J,K) - THE 

3 

REAL  TAU_F_INIT(I,  J.K) - THE 

0 

REAL  T_PL'LSE£_INIT!I,J,K) - THE 

120 


K=10 
PULSE 

REAL  LAMBDA  INITd, J,K) - THE  DISTRIBUTION  FUNCTION  VALUE 

0.5 

REAL  TAU_R  INITd, J.K) - THE  FIRST  PULSE  PHASE  VALUE 

0 

REAL  TAU  C  INITd, J.K) - THE  SECOND  PULSE  PHASE  VALUE 

S 

REAL  TAU  F  INITd, J,K> - THE  LAST  PULSE  PHASE  VALUE 

0 

REAL  T  PULSES  INITd, J,K) 
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DISTRIBUTION  FUNCTION  VALUE 
FIRST  PULSE  PHASE  VALUE 
SECOND  PULSE  PHASE  VALUE 
LAST  PULSE  PHASE  VALUE 
START  TIME  OF  THE  PULSE 


■THE  START  TIME  OF  THE  PULSE 


w 


R 

V 

c 


PKBLK 


PEN.0N.UNIT(I,J),J=1,1, 1=1,2 
PEN_ON_UNIT 

0 

0 


v 


k>.  > 


R  NEPARA 

V  INTEGER  N.UNITS - NUMBER  OF  DISTINCT  UNIT  TYPES 

V  TOTAL  NUMBER  OF  SAMS  AND  FIGHTERS  AVAILABLE 

F  N_UNITS 

2 

V  INTEGER  N.FIJYP - NUMBER  OF  FI  UNIT  TYPES 

F  NUM.FI.TYPES 

1 

V 

V  FOR  1=1. N  UNITS,  SPECIFY  THE  F0LL0NIN6 

V 

V  INTEGER  UNIT_TYPES ( I ) — THE  LITERALS  DEFINING  DISTINCT  UNIT  TYPES 

R  FIHEPARA 

F  UNIT  TYPES 

FI1 

V  REAL  TOT  FUEL  (I)— -THE  TOTAL  FUEL  CAPACITY  OF  THE  UNIT  TYPE 

V  CAPACITY  IS  IN  TERMS  OF  SECONDS  AT  CRUISE  SPEED 

F  TOTFUEL 

14400.0 

V  REAL  RADRANGE ( I ) — THE  RADAR  RANGE  OF  THE  UNIT  TYPE  (METERS) 

c  RADRANGE 

150E3 

V  REAL  T  MI  LOAD(I) - MI  LOADING  TIME 

F  TMILOAD 

0.0 

V  REAL  CRU 1 SE_ SPEED 1 1 )  — - — CRUISE  SPEED 

r  CRUISESPEED 

220.0 

V  REAL  DASH.SPEED(I) DASH  SPEED 

r  DA5HSPEED 

370.  C 

V  REAL  CRUISE  TO  DASH! I)— -CRUISE  TO  DASH  CONSUMPTION  RATIO 

c  CRTODASH 

5.0 

V  REAL  CRUISE_TD_FIGHT ( I >  — CRUISE  TO  FIGHT  CONSUMPTION  RATIO 

F  CRTOFIGHT 

5.0 

V  REAL  TURN_RATE ( I ) - TURN  RATE  (RADIANS/SEC) 

F  TURNRATE 

0.10 

V  REAL  CRUISE  TO  LOITER  (I)— CRUISE  TO  LOITER  CONSUMPTION  RATIO 

F  CRTOLOITER 
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1 


REAL  AUTO  RANGE(I.J) - AUTONOMY  RANGES  FOR  ’THE’  AND  'LOOS’ 

- CONTROL  NODES  (J=l,2) 

AUT0RAN6E 
S0E3,  I50E3 

tttmttt  END  OF  FIGHTER  SECTION  ntmUUUttttXMUUmttt 

» tmtttt  STATS  FOR  THE  SAN  WEAPONS  SYSTEM  UtmmttmtUUtt 

INTEGER  UNIT_TYPE5 ( I ) — THE  LITERALS  DEFININ6  DISTINCT  UNIT  TYPES 

KINEPARA 

UNIT.TYPES 

Nil 

REAL  T0T_FUEL!I) - THE  TOTAL  FUEL  CAPACITY  OF  THE  UNIT  TYPE 

TOTFUEL 

0.0 

REAL  RAD  .RANGE  (I)— THE  RADAR  RAN6E  OF  THE  UNIT  TYPE 

RADRANEE 

0.0 

REAL  T.HI.LOADfl) - HI  LOADING  TIME 

TMI LOAD 
330.0 

REAL  CRUISE.SPEED(I) - CRUISE  SPEED 

CRUISESPEED 

230.0 

REAL  DASH.SPEED(I) - DASH  SPEED  (MAX  FOR  HIS) 

DASHSPEED 

800.0 

REAL  CRUISE.TO.DASH(I) - CRUISE  TO  DASH  CONSUMPTION  RATIO 

CRTODASH 

0.0 

REAL  CRU I SE.TO.FI 6HT( I)—  CRUISE  TO  FIGHT  CONSUMPTION  RATIO 

CRTQFI6HT 

O.C 

REAL  TURN_F.ATE  ( I ) - TURN  RATE 

TURNRATE 

0.0 

REAL  LRUISE.TO.LOITER (I (--CRUISE  TO  LOITER  CONSUMPTION  RATIO 
CF.TOLOITER 
0.0 

REAL  AUTO  RANGE ( I, J) - AUTONOMY  RANGES  FOR  ’TITE’  AND  'LOOS’ 

- CONTROL  MODES  (J=l,2) 

AUTORANSE 

0.0. 0.0 


NUM.CQMM.INTERVALS  -  NUMBER  OF  INTERVALS  OVER 
WHICH  CONNS  DATA  WAS  COLLECTED 
NUM  COMM  INTERVALS 
2 

COMM. INTERVAL  TIMES  --  START  AND  END  TIMES  FOR 

THESE  INTERVALS 

COMM. INTERVAL  TIMES 

0.  5000 

5000,  1000C 

MEAN.DELAY  --  AVERASE  DELAY  OVER  EACH  INTERVAL 
MEAN.DELAY 
0 . oc”  C.00 

NUM.OD.PAIRS  ~  NUMBER  OF  LINKS  FOR  WHICH 
COMMUNICATIONS  WERE  OBSERVED  IN  ADCRM 
NUM  OD  PAIRS 


Goodness  of  Fft  for  Manual  ID  Time: 

Data  -from  Eglin  operational  test  o-f  CIS-ISS  in  May  1985. 


Histogram  stats: 


Interval 

Percent 

Cumt  | 

“TT 

to 

.  946 

26 

28. 3 

28.3 

.  947 

to 

1.563 

25 

27.2 

55 . 4 

1.564 

to 

2.  18 

17 

18.48 

73.9 

2.  181 

to 

2.80 

6 

6.52 

80.  4 

2.  80 

to 

3.41 

o 

2.  17 

82.  6 

3.42 

to 

4 . 03 

4 

4 . 35 

87. 0 

4 . 04 

to 

4.65 

7 

7.61 

94.6 

4.66 

to 

5.  26 

3.26 

97.9 

5.27 

to 

5.88 

o 

0.  0 

97.9 

5.e9 

to 

6 . 50 

n 

2.  13 

100.  0 

Mean  > 

=  1. 

86924 

minutes  <112  seconds) 

Var  = 

1 . 

94237 

mi nutes 

Sample  si 

ze  =  9 

Goodness  o-f  Fit  conducted  manually  and  with  AID  package. 
Both  indicated  that  exponential  was  a  "good"  -fit,  but  AID 
showed  lognormal  to  be  "best"  -fit.  Thesis  scenario  used 
g”E>eQ§Qt  i.a!  with  mean  o-f  112  seconds  due  to  model 
limitations  (e.g.  model  inputs  limited  to  the  same 
distribution  -for  all  service  times). 


§OQsDfss  of  Fft  for  CfS-XSS  ID  lime; 

Date  -from  Eglin  operational  test  o-f  CIS-ISS  in  May  1985. 


stogr am  stats; 

I nterval 

.  1 

to 

.669 

.  67 

to 

1 . 24 

1.25 

to 

1.81 

1.82 

to 

2.38 

2. 39 

to 

2.95 

2.96 

to 

3.  52 

Cr"? 

to 

4.09 

4.10 

t  o 

4.66 

4.67 

to 

er  k-r 

v-l  .  -U  J- 

5.24 

to 

5 . 80 

Etl§9uency 


Percent 

52.  8 
18.  1 
6.9 
2.8 
4.2 

5.6 
1 . 4 
4.2 
1 . 4 

2.7 


Mean  =  1.27806  minute®  (78  seconds) 

Var  1.95967  minutes 
Sample  size  =  y2 

Goodness  o-f  Fit  conducted  manually  and  with  AID 
Both  indicated  ■  1  ®t  exponential  was  a  "good  -fit-" 
scenario  usl  1  Eilponent i,ai  wi  +  r  mean  of  78  seconds. 


Cum.  */. 


70. 

77.8 
80.6 

84.8 
90.4 

91.8 
96.0 
97.  4 

1 00 .  o 


>ct:age. 
Thesi s 
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